Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.

POST & PUT

When I started this with you I only know about POST, which in your examples was used to 'update' and 'create' resources.
I see some docs have been referenced in a new Knowledge Base post that refers to the use of POST & PUT.

I see where implementing this distinction would be handy if sometimes you POSTed with a key or without a key(to represent a new resource).
In using the distinction of POST & PUT, The validation then being that POST must always have a key, and PUT has no key, or if it does, validate that it is not already created.

Just wondering, that is all. Too late for me to revert to this.

Comments

  • For those who really want to dive into these distinctions, I recommend reading the official RFC spec on POST and PUT.

    In simplified terms, POST should be used to create a new resource and the server gets to decide the resource ID. POST can also be used to append data to an existing resource, but the implication is that the existing data should not be modified.

    PUT should be used to create a new resource and the client gets to decide the resource ID. PUT can also be used to replace the data on the server. Thus, PUT should always send the entire resource data (both unmodified and modified) to the server since it is expected that the server will wipe out what it already has.

    The PATCH method has been proposed as an official verb to update parts of a resource on the server. The expectation is that whatever is sent to the server represents only the data that should be updated. All other data should be left alone. In our case, this would mean a JSON object with just a few fields rather than the entire record. Because PATCH has not been official adopted (AFAIK), not all servers support it.
Sign In or Register to comment.