Merge, Replace, or Patch: How Astoria Handles Changing Data


It seems that the team responsible for Astoria have decided to go for the traditional Microsoft “embrace and extend” approach to the beautifully simple world of REST.

The whole point of REST is that a GET is a GET and a PUT is a PUT. GET reads a resource, PUT updates it. These operations are idempotent and simple to implement both for the server and for the client. Any requests which non-idempotently change state should use POST.

It seems that, rather than put some thought into how to expose resources in a way which allows a combination of these basic operations to perform any needed task, the Astoria team have decided that new HTTP verbs are required, and are now championing the addition of a MERGE verb.

This is (in my opinion, of course) flatly wrong.

Conceptually MERGE is a loosely defined operation, which will by its nature be implemented differently in different contexts, so nether the client software nor the network infrastructure will be able to make any simplifying assumptions. Worse, if it comes into any kind of common usage it will effectively require all servers and clients to be aware of it.

This verb is simply not needed. If the resources being addressed are too big for a GET/modify/PUT cycle on a whole resource to be effective, just provide a way of addressing parts of the resource.


InfoQ: Merge, Replace, or Patch: How Astoria Handles Changing Data


  1. If I can use an analogy to that in my own domain, a GET would be a SELECT, and a PUT would be an INSERT or, if the data exists, a DELETE followed by an INSERT.

    UPDATE works in the SQL area, presumably because it is defined. Would you be satisfied if MERGE were well defined, or is that not possible?

  2. My point really is that it can never be fully defined. How should I merge two JPG images? How should I merge two timestamps? How should I merge two sonnets?

    Even if they can be defined in some way, how should I merge a JPG image with the result of merging a sonnet and a timestamp?


  3. I see what you mean. It’s all very well talking about data records. It’s quite another thing with that “other stuff”. I expect they’ll dream up some polymorphic OO scheme, where objects provide their own management API. As for merging an “apple” with an “orange”, it makes no sense. MERGE can only function on things where MERGE is rational. The problem then becomes – is the Astoria team rational!

Comments are closed.