If your course has 20 member variables, now you have 20 update methods? If you want to update multiple, the client then needs to do multiple round-trip calls to your API which is time-consuming: if it's a 350ms round-trip per call, updating all 20 fields takes 7 seconds. And unless you go out of your way to offer per-object locking (which over a stateless connection has its own challenges) you prevent users from doing atomic updates to multiple fields at once. This pushes any rollback mechanism onto the client, exactly where it should not be.
With your design, if your goal is to "combine all the parameters in one place to keep things simple", you could go one step further and have:
POST /course/update {courseId: 1234, field: "description", description: "hello"}
Taking this to its logical extreme, you can truly combine all the parameters in one place:
Like any other programming language if you need to update multiple fields, you pass multiple parameters to the function. The URL should be equivalent to namespace/class/method while the parameters are just that - parameters you can pass in JSON format.
You're putting the burden of learning implementation details of your system onto your customers. That won't be comfortable for either them or you. Should you need to deprecate a method you'll never be able to remove it. So be prepared to write a lot of { "Error": "ErrorCodeThatOnlyMakesSenseInTheContextOfThisAPI", "Description": "DEPRECATED" }
With your design, if your goal is to "combine all the parameters in one place to keep things simple", you could go one step further and have:
POST /course/update {courseId: 1234, field: "description", description: "hello"}
Taking this to its logical extreme, you can truly combine all the parameters in one place:
POST / {object: "course", operation: "update", courseId: 1234, field: "description", description: "hello"}