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.