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

UPDATE api.example.com
SET [/invoices/12345/delivery-date/] = ‘2007-03-15′

What HTTP can’t do is update more than one ‘record’ (resource) which is why the WHERE clause is not needed.

Of course you could argue that HTTP PUT has more power than SQL UPDATE because most SQL implementations cannot do this. Here’s my TSQL psuedo-code showing the ability to declare an “invoice resource”:

DECLARE @Inv12345 AS ‘invoice-resource’
EXEC prc_GetInvoice @InvoiceNo= 12345, @invoice= @Inv12345 OUT
UPDATE api.example.com
SET [/invoices/12345/] = @Inv12345

However, with the ability to store JSON in TEXT fields or XML is XML fields, SQL *can* do that (well, you can’t index into JSON and update portions of a JSON resource using SQL like you can on many servers with XML and XPATH.)