The REST in PRESTO

One of the intents (successful or not) of PRESTO has been to gather the various "shoulds" or "mays" floating about concerning permanent URLs, REST, etc, and see where "shalls" gets us.

Roy "Mr REST" Fielding recently made an interesting post No REST in CMSI about the CMIS (Content Management Intereroperability Services) web services being mooted by EMC, Microsoft and IBM.

I don't know enough about CMIS to make any comments on it. But Roy Fielding's characterizations of what REST is about is helpful for understanding what PRESTO is about. Here are some of his comments about CMIS and my reaction about their implication for PRESTO.

CMIS is a classic example of what happens when a control-oriented interface is slapped onto an HTTP-based protocol instead of redesigning the interface to be data-oriented.

The term data-oriented is a good one. In PRESTO terms, every significant object at every significant level of granularity should have a clear, permanent URL?

An HTTP interface doesn't need to traverse folders or query databases in order to access an object summary that points to a content stream that might then be downloaded; hypertext allows each object to be identified by a URI and manipulated independent of the discovery process.

In PRESTO terms, this relates to the O (objects): just as programming languages with first-class objects allow introspection (asking an object what it is) and reflection (detailed introspection so you can ask an object what it contains), not only do you nounify (resourcify, identify) sub-resources but also the super resources.

An HTTP interface doesn't need to forbid the versioning of folders; hypertext can tell the client what operations are allowed on each folder.

Again, it looks pretty compatible with PRESTO. Move as much as possible to the URI. Make resources (data-oriented systems) rather than functions (process-oriented). And actually make the resources traverse-to-able by having hypertext links from their super-resources.

PRESTO would go further, perhaps, and say that you should have URIs for resources even if those resources do not have representations handy at the time: I think this is fine under REST, because you then rely on the vanilla operations of HTTP rather than any superimhacked protocol.

I think that constructing an interface that can be maximally used by standard clients is a good first step and one that can be done by any ECM vendor without need for an additional standard beyond HTTP, WebDAV, AtomPub, and the various hypertext-aware media types. However, the second step is not to make CMIS-specific protocols, data formats, and relationships that are spread all over the data willy-nilly.

We are talking about generic web-based content management using universally accepted notions of folders, documents, and (at least fairly common) versioning operations. They deserve equally generic typed relationships and standard client behavior that doesn't rely on out-of-band information and model-specific protocol tweaks. Having a lot of little standards only works well when they don't overlap. ...

The focus should therefore be on enhancing the media types and relation types with those universal concepts in a way that will still work as a subset for more advanced back-end data models. If we need a query interface, then it should be designed as an Atom query construction mechanism within the Atom format. It should be defined by the interface presented across HTTP, not by the interface underneath the back-end.

This idea, that you try to maximally use the generic operations of HTTP and only resort to queries and protocols when all attempts to resourcify, hyperlink and use HTTP run out, is very much where I think the PRESTO approach leads.