|
|
|
|
|
|
by dexen
5028 days ago
|
|
|
> Can someone who's worked with APIs that accept updates give a code example of something that would be better if you accepted patches instead? Concurrent edition of tabular data by several users. User loads a HTML <form> with a bunch of widgets into her browser, edits some of the data and <submit>s. The usual implementation causes all data submitted via HTTP POST request, as simple KEY=VALUE dataset. Should two users send POSTs of same resource (same URI) concurrently, it is not clear what are real changes and what is unchanged, nor how to apply it to the resource. What I'd like to do -- and indeed, some parts of my software does, albeit in non-standard way -- is submitting diff, in form of KEY=<original-value, new-value>. Makes it easier for the backend to serialize users' changes, and either apply them in atomic way or reject just the conflicting ones. |
|
|
As I keep looking at this, it seems that it's most valuable when you consider the patch as an element of an event-based system, where you're storing or operating on changes rather than just the data. The reason it helps with a bulk editing process is that you want to know what changes Alice and Bob made if they both submit at the same time - operating on diffs simplified the system. For other systems where you operate on diffs, like an audit log, it's helpful to have a first-class format that defines the diff on a JSON document.
I think that's the biggest caveat I'm seeing with the proposal. It's pitched as a way to handle HTTP PATCH requests, but a format that defines "diffs on JSON documents" is most suited for systems that primarily store JSON documents and diffs on JSON documents - it is much less broadly applicable for "HTTP servers that accept JSON data", since frequently they only work with JSON over the wire, not as the ultimate source of truth. If you don't store JSON documents as the ultimate source of truth or have a domain-model reason to want diffs, I'm unsure of the advantage.