4 ms·

If you treat the document as a collection, you can usually map a url to the particular property that needs updating and accept PUT to that. But that can be a pa

by tjpick 17y ago

If you treat the document as a collection, you can usually map a url to the particular property that needs updating and accept PUT to that. But that can be a pain if you don't know in advance which particular properties will be updated. I could also see implementing a server that accepts PUT with a diff format and just apply that patch instead of replacing the document. Some of it seems well thought out but there are other bits that smell a bit fishy to me > For example, if the patch document size is larger than the size of the new resource data that would be used in a PUT, then it might make sense to use PUT instead of PATCH.

DougWebb 17y ago
On one of my projects I did something like this. I needed to create a resource atomically even though it was composed of many files. To accomplish this I established a container resource that the client could PUT to with a tar.gz file, and the service would unpack the files into the container. The body of a PUT request is intended to specify a new representation for the resource, but there's nothing in the standards that say that the format of the PUT body has to match the final resource. Gzipping, compressing, and chunking the representation as it travels back and forth are explicitly supported, so why not PUT a representation that represents the differences between the old and new version of the resource?