To add a new resource, I ‘POST’ to the collection url and get back a unique identifier. I can use it then and there to ‘PUT’ a resource OR I can forget about it — the server agrees to never hand out that same ID again — whether it actually creates the ‘empty’ resource a that ID or not can be an implementation detail (it may be useful to have a return code other than 404 in response to a GET on that id — something that says ‘no resource at this ID, but it has already been claimed’). So implementing POST on the server is pretty simple….

Any thoughts on that?

Elias Torres Says:
… and there’s always PATCH.

No there’s not. You’re reading a DRAFT of the HTTP/1.1 spec. The FINAL spec does not include PATCH or many of the other (arguably useful) methods in it (like COPY, MOVE, etc. though these are in Webdav to a certain extent).

http://www.w3.org/Protocols/rfc2616/rfc2616.html

The only thing you can do in HTTP is send the entire resource again, to completely replace the existing resource. There’s really no equivalent in SQL, but if you must have one, then PUT is like a DELETE, followed by an INSERT, using the same primary key.

There is an equivalent in MySQL called REPLACE, which does exactly that (and is not recommended because of the index churn it causes).

Partial updates are also important for high transactional web apps. Often times you only want to update select columns in a table, as some may rarely if ever change, or changing them could cause index updates and other side effects that could be avoided. I’ve worked on enough projects where always trying to update everything can cause contention and other nasties in the database.

HTTP methods should be used in the context of the resources they’re being applied to, as the RFC is not a panacea