Search code examples
restpostasp.net-web-apiput

mix POST and PUT for updates in rest service

I know this is probably the gazillion'th time a thread has been started about this, but I cannot find an answer to my specific question.

We have an internal discussion whether or not to use PUT for updates in our rest service. We have agreed that using PUT has the preference. However, PUT needs to be idempotent. Does this mean that we should mix POST and PUT verbs for different update routes according to their idempotence?

As a concrete example. We have an update route, that updates, let's say a "car". To this update route, you can (among other things) pass a hyperlink. This hyperlink will get an id when saved, and will be linked to the updated car. However, every time you update on the car, the generated id of the hyperlink will be different. Does this mean the update is no longer idempotent? Even when the actual target of the hyperlink is the same?

If so, we should use the POST verb for this update, instead of the PUT verb. However, we have many other update routes that ARE idempotent. Should they remain PUT? I believe this can become very confusing for the consumer of the service.

In short:

  • is it a good idea to mix PUT and POST for update routes according to whether they are idempotent or not?
  • Or does consistency of verbs trump the idempotent rule, and should we simply use PUT for all update routes?
  • Or should be just let go of the idea of using PUT and use POST everywhere to avoid the confusion altogether?
Solution

  • I've had some discussion with people outside of stackoverflow. We came to the following conclusion:

    • Mixing POST and PUT for updates is not a good idea, it is confusing for the consumer
    • Consistency trumps the idempotent rule of PUT
    • Using post everywhere is not a good idea because of people being used to use PUT for updates

    Ideally we would alter our code (from the example in the initial questions) to make sure that the id's of the hyperlinks don't change. In this case there would be no discussion about using PUT or POST. If we cannot do this, we will write a "disclaimer" in the API readme to make sure to let people know some PUT routes are not really idempotent