I was working on a Delphi project using Indy's network components, when I noticed a method called "Patch".
Hm. What's that?
A quick Google brought up a discussion of what Patch is and how it's intended to be implemented. Rather than using a partial state representation with the HTTP PUT method, the new (as of 2010) PATCH method allows sending up a description of how to modify a resource in order to apply changes to only portions of a data state.
It didn't take long for me to reject this for the projects I work on. Notice I didn't say I would *never* use it. I'm sure there's a system somewhere where PATCH is the correct solution, but in my case I'm applying changes to customers, inventory, invoices, that sort of thing. Y'know, basic database stuff. For me, a PUT in which the only columns that will be updated are the ones referenced works perfectly. It's succinct, and by using optimistic locking, I can use row versioning to protect against write collisions.
The entire reason for using something like PATCH is to minimize the payload instead of sending the entire data state in a PUT body. The problem is, besides actually adding far more to the payload than it saves, is the added complexity of processing a payload that could have more instructions in it than simply "update this column with this new value".
In my case, if I just want to update a customer's middle name, I send this (if it's in JSON):
I don't apply anything else, so we're okay. If I want to empty the middle name, I might send either of these:
-- or --
Simple, right? I've been working on REST systems for 9 years now, and that approach has served me well. I've heard that PATCH, as well as partial PUT, is neither safe nor idempotent, and I disagree with that. No, it's not idempotent over the entire resource, but is it safe? That's a matter of proper validations on the server side.
On the other hand, it doesn't take a lot of creativity to come up with a use case at which PATCH would excel. If the resource being modified was large and unstructured, for instance, I really only have two alternatives: to do a full PUT, or a PATCH in which I indicate what bytes to remove, to insert, and to replace. A REST based video editing service is a good example of something like this. I wouldn't want to upload the entire video, but a user's edits to the video could be sent up as small operations against the large body of the video.
One last note. When I was architecting a REST API on a major system I worked on, at the time the GUI side developers argued that no one was strictly RESTful and that attempting to implement strict REST was a waste of time. I found it interesting, in my research on this topic, that REST implementations have become, if anything, more concise and consistent, with the state of RESTful architectures maturing towards a single philosophy when it comes to HTTP REST systems.
Copyright (c)2014 Todd Grigsby, all rights reserved
