Alex Jacobson 3.0

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!

On Sam Ruby’s blog, Simon Fell suggested using digest-auth to proect user weblogs when they post at conferences etc.

This suggestion is misguided. The only thing that digest auth secures is passwords themselves. It does NOT prevent a man-in-the-middle from modifying the content of a POST to anything it/he damn well pleases. It does NOT prevent a MITM from modifying the content of an HTTP response to generate lots of javascript or 30x redirects requests to give lots of request tokens with which to play.

Someone on a conference net providing their own DHCP/DNS could have lots of fun with people relying on such primitive stuff. But, hey, at least they won’t get passwords!

If you actually care to prevent third parties from POSTing as you, use SSL or some content-level standard like PGP, S/MIME, or XML-DS that is less vulnerable to trivial MITM attacks.