2

We have a requirement to develop a REST API that updates a resource. Including:

  • Updating properties values
  • Adding\removing properties

Now, we have 2 alternatives:

  • Using PUT (following a GET)
  • Using PATCH

We know, that the PUT original meaning is the replace an existing resource – so, in order to use PUT, and answer the requirements, we should enable the API consumer, to GET the resource details, and send a PUT request with ALL the details, in order to replace the old resource details. This way, we allow him to update\add\remove properties. But… we would also need to handle concurrent updates. This should probably be done using optimistic-concurrent-control (e.g. using if-modified-since headers).

Alternatively, we can use PATCH – that its intention is to partially update resource. PATCH – with its special syntax – allows updating\adding\removing properties, without the need to supply the full resource details -> so we do not need to GET the resource details first. Here, no need to handle concurrent updates.

We think that the correct solution is PATCH. But… We looked on some well-known REST APIs and we did not see PATCH used widely. Moreover, we saw some (few) articles about problems using PATCH (firewall blocks, clients that does not support it out of the box, etc…). For example:

How to use the PATCH method in HTTP adapters?

How do I stop Apache httpd from rejecting HTTP PATCH requests?

From your experience, should we use the correct thing (PATCH), but risk rejects from consumers? Or should we use the GET+PUT and risk/handle the concurrency issues?

Thanks in advance!

Community
  • 1
  • 1
Nir Zamir
  • 111
  • 1
  • 5
  • 1
    PATCH also supports if-modified-since and ETag headers, which you should use in order to gurantee that only fields are updated if the resource was not modified in between. Also, PATCH operation is defined as atomic, which means either all operation succeed or none of them. This adds transactions requirements to PATCH. Further. PATCH sends instructions to the server to modify the resource from state before to state afterwards and is not a partial PUT where you just send the fields to update to the server! In addition to that, PATCH is not idempotent – Roman Vottner Jul 20 '15 at 12:55
  • [Good article on PATCH](http://williamdurand.fr/2014/02/14/please-do-not-patch-like-an-idiot/) – Roman Vottner Jul 20 '15 at 13:01
  • Thanks. I'm especially interested in getting concrete examples where using patch is problematic (probably due to consumer limitations). – Nir Zamir Jul 20 '15 at 13:17
  • JAX-RS 2 for Java does not automatically support PATCH, but [it can be added](https://blogs.oracle.com/theaquarium/entry/using_http_patch_with_jax). SpringMVC does support PATCH to my knowledge. Also Restlet does support PATCH. All of these also provide client libraries and therefore should support PATCH in one way or the other. Concerning other frameworks, I can't give any details – Roman Vottner Jul 20 '15 at 13:22

0 Answers0