ReST vs MoST (a free blog API)

Abstract:
ReST means you can’t know how the meaning of a GET response without external documentation. MoST means knowing the meaning of a GET response at the cost of abandoning (rarely used) content-negotiation; with MoST, the content-type of a resource completely determines its API.

ReSTful service specifcations are complex documents that define various content-types, the association of those content-types with various HTTP methods, and verbose descriptions of what happens when those verbs are actually used. In effect ReST views HTTP a computation interface; Servers hide data models and themselves implement views and controllers. See e.g. Tim Bray’s attempt to specify an echo/pie/atom API

ReST complexity is a result of failing to acknowledge that HTTP really is a communication interface between various server and client agents. The semantics of all HTTP applications is communication about the state of a model. All the work in ReST style specs involves creating custom interfaces to custom viewers/controllers of some ostensibly hidden model

If we instread acknowlede that HTTP is really communication about the state of a model; that HTTP services expose Models and let user-agents implement viewers and controllers based on those content-type. In effect I am proposing a Model State Transfer architectural style.

MoST style means defining standard HTTP interfaces for various server content-types. The most useful of which is probably text/XML (because we then get a weblog API for free).

GET /myRSSblog returns an XML document.
POST /myRSSblog#channelId adds a new child to the XML node with that id.
GET /myRSSblog#itemId returns an XML node with that id
PUT /myRSSblog#itemId replaces the XML node with that id
DELETE /myRSSblog#itemId deletes the XML node with that id
(Style using <?xml-stylesheet type=”text/xsl” href=”yourstyle.xsl”?> for your viewing pleasure.)

(Update: A permalink is simply a link /myRSSblog#itemId)

Note this works with an RSS feed. You can use the exact same plumbing for an pie/echo/atom feed or for any other data-model described by an XML schema.

The big advantage here is that the semantics of the API is now defined by the schema of the resource and the syntax by its content-type. Nothing else is required! If you want a richer interface, make a richer schema.

Have fun!

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: