Representational Value Transfer (REVAT)

(written by lawrence krubner, however indented passages are often quotes). You can contact lawrence at: lawrence@krubner.com, or follow me on Twitter.

Very interesting:

Representational Value Transfer (REVAT)
What we need is a RESTful way to disambiguate state and value, so that we can reason about resource URLs. I propose that we use use existing REST semantics for indicating state and adopt a new conventional standard for indicating values:

GET http://api.example.com/values/5690ba7f-f308-4c32-b67c-56f654bbfd83

{
“id”: 12345,
“title”: “Apple iPad Air”,
“price_usd”: 599.99
}
The salient points of a REVAT URL are:

REVAT values are immutable.
Values are identified by random UUIDs
No coordination is required to uniquely generate them
A non human-friendly identifier hints that this thing cannot be changed
A client may store new values in two ways:
POST http://api.example.com/values/ in which case, the server generates a new UUID to identify the value.
PUT http://api.example.com/values/ when the identifier is supplied by the client. Any attempt to PUT or POST to an existing value must fail with 409 Conflict.
Unfortunately, there is no formal way to specify that a resource is immutable, and therefore never-expiring with HTTP headers. According to RFC 2616:

To mark a response as “never expires,” an origin server sends an Expires date approximately one year from the time the response is sent. HTTP/1.1 servers SHOULD NOT send Expires dates more than one year in the future.

This, however, is not a robust solution, so REVAT resource responses, in addition to setting an Expires header one year in the future must also specify the header Immutable. This header has no associated value; its presence indicates that the body of the response is immutable and may be cached indefinitely.

Since the value is immutable, when you receive a REVAT URL, you may do anything you please with it, without any worry over consistency semantics:

You may store it indefinitely
You may pass it to other services
Everybody that sends and receives a REVAT URL is guaranteed to be talking about the same thing.
Think of a REVAT resource URL as a named value, like

Post external references

  1. 1
    http://teddziuba.github.io/2014/08/18/the-s-in-rest/
Source