S
S
Sergey Blokhin2017-10-27 15:53:47
RESTful API
Sergey Blokhin, 2017-10-27 15:53:47

Behavior of REST DELETE requests in idempotency?

The article Introduction to RESTful Services states that:

Idempotent Two other basic HTTP commands commonly used as part of the Uniform Interface are PUT and DELETE. The PUT command is most commonly used when the user agent needs to modify a resource, and the DELETE command is self-descriptive. The important point (and this is what the term "idempotent" describes) is that on a given resource , these two commands can be used multiple times, and the result will be the same as when they were first used - at least there will be no additional effects. This is encouraging when building robust distributed systems where bugs, network failures, or latency can cause code to be repeatedly executed.

Do I understand correctly that when implementing a method on the server side DELETE, you must always respond with a positive response.
I'll give you an example.
The client executes the request DELETE /user?id=42twice.
The first time he gets an answer 200 status: true.
What should come with a second request?
  1. 200 status: true
  2. 4xx status: false, error: user_not_found

Answer the question

In order to leave comments, you need to log in

1 answer(s)
�
âš¡ Kotobotov âš¡, 2017-10-29
@angrySCV

A dubious statement, perhaps something was messed up with the markup of the text in the translation.
If the request is idempotent, then it can be cached, neither put nor divides can be cached.
again I went to the wiki and looked, it says that for example PUT returns different statuses if there is changeable content or it is not there when sending.
In general, nothing prevents you from implementing the same answers. There are no strict standards, there are only general recommendations. For example, I like the option for DELET with the same answers.
Then the server's responsiveness will be higher, since you do not need to wait for the end of the task to send the status (that is, you can send the deletion task to the server asynchronously and return status 200 without waiting for the result).

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question