HTTP PATCH, new entrant

A new action has been adopted to HTTP in March 2010, named PATCH along with GET,POST,POT,DELETE etc.

Before going in detail about PATCH, let's have quick look at PUT and POST and the basic differences

POST to create a new resource when the client cannot predict the identity on the origin server (creating a new purchase order)

The actual function performed by the POST method is determined by the server and is usually dependent on the Request-URI. The posted entity is subordinate to that URI in the same way that a file is subordinate to a directory containing it, a news article is subordinate to a newsgroup to which it is posted, or a record is subordinate to a database. {source RFC}

PUT is to override the definition of a specified resource with what is passed in from the client

The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI.

So the fundamental difference in PUT and POST is that , in a POST the URI mentioned will handle the entity enclosed in the request, or in other words the entity is a subordinate of the URI. Where as in PUT , the URI identifies the entity enclosed in the request.

Most of the developer community avoid using PUT, may be because forms doesn't support that.

Why need a PATCH

The existing HTTP PUT method only allows a complete replacement of a document.New HTTP method, PATCH, to modify an existing HTTP resource.PATCH to override a portion of a specified resource in a predictable and effectively transactional way (if the entire patch cannot be performed, the server should not do any part of it). The PATCH method requests that a set of changes described in the request entity be applied to the resource identified by the Request- URI.

The difference between the PUT and PATCH requests is reflected in the way the server processes the enclosed entity to modify the resource identified by the Request-URI. In a PUT request, the enclosed entity is considered to be a modified version of the resource stored on the
origin server, and the client is requesting that the stored version be replaced. With PATCH, however, 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. {RFC}

PATCH is neither safe nor idempotent ,but can be issues as idempotent

Who needs PATCH

In the REST-style of architecture is important to use the appropriate HTTP Verbs and the REST depends on URI for resource identification. "High" REST means the proper and full usage of all the verbs;GET, PUT,POST and PATCH in the days to come.

Then the semantic web need these partial updates than the complete replacement of the documnet.http://www.w3.org/Submission/SPARQL-Update/

There are currently no standardized patch formats in wide RESTful use, but they are likely to be designed for XML, HTML plain text and other common formats.