#rfc2616

Baucis has users spanning the globe. From San Francisco to New York, London to Tokyo. Build your next REST API with Baucis!

While you're waiting on v0.16.0 and the new streaming features, why not check out what's being said about Baucis around the world?

Servizi REST con NodeJS + Express + Mongoose + MongoDB

Marionette.js(Backbone.js)のチュートリアル with yeoman その１(準備からサーバー側実装まで)

Einführung in den MEAN Stack: Teil 10

Getting Started Full Stack, Node.js Backbone.js MongoDB

PATCH is only a proposed standard (RFC5789), granted a widely used one. I think fundamentally it addresses a need that doesn't exist, because there's absolutely nothing in the HTTP spec (RFC2616) that states you can't use PUT for full or partial updates (or both or neither).

A lot of room is left to interpretation for the server implementation, and rightly so.

Other areas are explicitly defined. It's hard to understand how a reading of the spec can lead one to think of POST as an update. I covered that a bit in the last post.

A common statement is that arguments about REST are overly theoretical, and perhaps some are, but often there are subtle advantages to rigorously following the specification.

One example of the advantage of using PUT as the spec outlines is this: PUT is idempotent, so a browser (or proxy) knows it is fine to retry a failed request. POST is not defined to be idempotent, and therefore it would be inappropriate to retry the connection.

Another advantage is that as client logic continues to (finally) detach from the server, and is moved to the browser, relying on standard semantics means clients can be more generalized, and just know that if a resource is to be updated, a PUT to that resource's URL should be used. The server defines much of how to interpret the PUT request's body, headers, etc.

Clients are all the time moving closer and closer to being implemented solely in the browser using technologies such as HTML5, RequireJS, Backbone.js, and static hosting — no client code hiding in the back end. (I should mention Bower too. It incredibly tames the tangle that is client-side package management.)

The interpretation of RFC2616 as mapping directly to CRUD is a beautiful thing. Not only can most, if not all, of the "database" (REST API) queries be moved to the client, but standard HTTP technologies like caching proxies can be used.

Another advantage to using standards is lower development time, and therefore lower project cost. For example, the infamous cache-busting query parameter is used to workaround caching of GET requests. Sure, the cache-buster works but you have added complexity when a standard solution was already available, a much more powerful and efficient alternative was right under the developer's nose: the cache control headers such as Last-Modified and ETag, already a part of HTTP.

On a final note, things like supporting deleting properties of a resource vs. just being able to set a property to null, or overwriting the object without knowing its current state are implementation details, and I would think this is why the spec largely leaves such considerations to the server implementation.

For example, in a JSON API, you could set a property to e.g. { $del: true } to delete it, or if the semantic meaning of having the attribute, but storing a value of undefined or null instead of deleting the attribute is really meaningful, you could use other means to specify this.

A key question there is do these distinctions have semantic meaning in the context of your API, and if they do, is there a more straightforward way of representing this semantic?