Timeline for REST API Design: Should the update (PUT) request include the ID in the resource URL?
Current License: CC BY-SA 4.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 14, 2022 at 17:49 | comment | added | Ewan | no. i agree with you that the URI is the resource meant by the spec. I guess im trying to squeeze through updating a different resource "books" with the side effect of changing "book/1" | |
| Feb 13, 2022 at 21:39 | comment | added | amon | The point we disagree on is how the resource is identified – I and the standard use the URL for this, you propose that the request body should participate in resource identification. I think we both can agree that the request might have side effects. For example, PUTting a new book might change the list of books in the author's resource. | |
| Feb 13, 2022 at 21:16 | comment | added | Ewan | seems like there is a handy get out clause "A PUT request applied to the target resource can have side effects on other resources." | |
| Feb 13, 2022 at 18:40 | comment | added | amon | I think this is given by section 4.3.4 of RFC 7231: “The PUT method requests that the state of the target resource be created or replaced with the state defined by the representation enclosed in the request message payload.” The “target resource” is identified by the request URI (compare section 2), not by the payload contents. | |
| Feb 13, 2022 at 17:40 | history | edited | Ewan | CC BY-SA 4.0 |
added 733 characters in body
|
| Feb 13, 2022 at 17:24 | comment | added | Ewan | link to spec where it says that? | |
| Feb 13, 2022 at 15:50 | comment | added | amon | For a POST request, I'd agree. But for a PUT request, your recommendations violate the semantics of this request type. | |
| Feb 13, 2022 at 14:59 | history | answered | Ewan | CC BY-SA 4.0 |