Last week, while meeting (over Zoom) with my morning discussion group from the Flatiron School, we found ourselves looking at a list of HTTP verbs to try and match them with their respective CRUD (create, read, update, and delete) actions. We found that two verbs, at first glance, could both fulfill update duty for a web application, so we decided to take a deeper look, even if it was for five minutes.
POST method, Hyper Matter Transport Protocol, circa 24th century
The most alert among us (it was about 9:30 AM) quickly skimmed stack overflow threads on the topic aloud. The prevailing summary we gathered from our brief google excursion was that PUT is used to just update a whole file, while Patch is used for updating only specific portions. Upon looking for a good enough description, I found this:
With PATCH... the enclosed entity contains a set of instructions describing how a resource currently residing on the origin server should be modified to produce a new version.
Of course, that couldn't be enough for me. I wondered further, "which came first? PUT or PATCH? Is PATCH some old HTTP verb from the 90s?"
Of course I'll write a blog that requires me to read Internet Engineering Task Force specification documentation!
What I found
I decided to go straight to the primary source of information regarding the PATCH verb, the PATCH proposal documentation from the Internet Engineering Task Force, where I was able to confirm (based on what a group mate previously told me) that the PATCH verb was a recent addition to the Hypertext Transfer Protocol, the method was proposed in March 2010, long after many in the most developed nations have moved on from slow dial up connections could have reaped benefits from a seeming incrementally updating feature. By contrast, the PUT method was proposed in 1999 (here is a great Quora response that cleverly answers the difference between PUT, POST and PATCH).
A big difference between PUT and PATCH is that the PUT method is idempotent, or that, every instance of a given data update via PUT method will be the same (an example would be mashing a submit button that sends the same data in a put request... the data can be sent 100 times and it will be the same). That's a clear difference to the nature of the PATCH method, which allows updates to a specific part of a larger resource. While PUT always overwrites a whole resource, and an instance of an update doesn't change, every instance of a PATCH request doesn't have to be the same, or idempotent.
The nature and resulting problems with using PATCH
Lacking the necessity of being the same, there comes other inherent ramifications to using a PATCH request as opposed to a PUT request. Because there are formats and standards to send data, application of a patch method is inherently non-universal. In plainer english, in almost every differing format of data, a developer will have to come up with a new wheel design to update a small part of that resource using patch. While it might be easy to change send a key value pair in a JSON collection, it might be much harder to try and change a line of text stored within a blob in a relational database table.
An example of a PATCH request being shorter than a PUT request by sending specific data. From https://stackoverflow.com/a/21661036/5456075
A developer also has to weigh the risk that, with making custom headers and means to patch an update to a given type of resource, the resulting PATCH method might be bigger than just using a PUT method that simply overwrites the whole older version of a resource. Other potential horrors awaiting a developer if they attempt to implement a system utilizing PATCH updates include:
Potential staleness of requests (if a newer request reaches the server before the older one).
Malformed, or improperly formatted, patch documents (possibly as a result of lack of a universal standard formatting for the patch method).
Servers improperly configured to support PATCH requests.
Finally, the incremental/piecemeal nature of PATCH requests makes it easier for bad actors to gradually send malware such as a virus that can gradually be "patched" together on a receiving server (it's much harder to do this with PUT and POST requests).
Of course, these are all downsides if a developer wants to build a solution from scratch. As I learned recently, frameworks such as Ruby On Rails utilizes PATCH requests effortlessly because of the collective brainpower that goes into developing solutions of that scale.
Conclusion -- And Thinking Fourth Dimensionally
Don't worry Marty, tracks will be there in 100 years
So, why care about the differences of PUT and PATCH? Why care about how it's implemented if it's already utilized in frameworks like Rails, I won't ever care to know the difference! Maybe you won't, but the method was only proposed in 2010, it's been around for a short amount of time compared to other HTTP verbs. When PUT was first introduced, it took time for its usage to be adapted because of the perceived overlap it shared with POST, but now, the two are used for separate and important concerns. The reason why I wondered if PATCH was a holdover from some bygone era involving 56k modems was because of the potential for the method to send small amounts of data, something that would speed up internet communication for users using low bandwidth or unreliable connections. In the west, we may have moved away from 2g and 56k modems, but the developing world is only now getting access to relatively expensive, data capped connections to the internet.
While users in the developed world can wave off such considerations of importance and savings of data utilization, developers have to consider the problems and frustrations users in the developing world face. The internet of the near future cannot always be about transferring Cadillac sized requests between client and server, and considering more specific and concise requests will be ideal.
Top comments (1)
This is such a in depth study about put and patch! Thank you