-
Notifications
You must be signed in to change notification settings - Fork 901
POST is not always "create" and PUT is not always "update". #13
Comments
I'm not entirely sure, but it seems that the HTTP Verbs chart https://github.com/WhiteHouse/api-standards#http-verbs is trying to avoid the sort of ambiguity that the HTTP protocol introduces (http://tools.ietf.org/html/rfc2616#page-51) in regard to POST, PUT, and method overrides. For instance the chart says the the PUT method should only update and if the entity doesn't exist it should return an error. In the HTTP spec it is entirely valid for an origin server to only update entities when the PUT method is used as long as the server returns the correct status code
(http://tools.ietf.org/html/rfc2616#section-9.6) However, there is some ambiguity that isn't clarified here in regards to the responses from the PUT and POST methods.
(http://tools.ietf.org/html/rfc2616#section-9.5) Further if the action doesn't result in an entity with a URI we know it's appropriate but not required to return a 200 or 201 response.
(http://tools.ietf.org/html/rfc2616#section-9.5) |
This is somewhat minor, but the document says that HTTP POST is a "Create". That is not correct. There is no one-to-one mapping between CRUD and HTTP verbs. It boils down to whether the operation is idempotent or not.
HTTP POST is non-idempotent, HTTP PUT is idempotent.
As for CRUD: Create can be both idempotent (if you provide ID of the record that ought to be created, e.g. you are creating a user with specific user_id) or non-idempotent (if you provide data but not the ID). So there're many cases where PUT is absolutely fine for a Create operation.
Furthermore, many services do not support anything but GETor POST. This is because browsers do not support any other verb so lots of proxies and most CDNs also only implement GET and POST with zero support for anything else. We have had some conversations with major CDN providers to address this very issue and I know some of them are actively working on it. Point is: a lot of pragmatic APIs implement POST for "delete" and "update" with so-called Method Override.
Speaking of which, this document could probably use a word or two about method overrides.
The text was updated successfully, but these errors were encountered: