3 ms·
Agree with your sentiment, but I've always seen PUT as idempotent, not POST. Typical rest usage has POST creating new objects, and return the object with a new
by wglass 5y ago
Agree with your sentiment, but I've always seen PUT as idempotent, not POST.
Typical rest usage has POST creating new objects, and return the object with a new id. That's not idempotent. Doing it repeatedly makes new objects with new unique IDs. PUT is updating a given object, with the id in the URL. If you do it repeatedly, it's the same as a one time call.
POST /user
--> returns user with id
PUT /user/12345
--> stores the data in the body for user with id 12345
PATCH /user/12345
--> merges the body with the existing object that has id 12345. (used to update specific field or fields)
- deleted 5y ago[deleted]
- dariusj18 5y agoThat seems to muddle interface with implementation. What if your underlying architecture creates new versions of records when they are edited. That wouldn't be idempotent but you wouldn't change your API.