Objects at REST
by Rick Jelliffe
One reason, of course, is that the term Object-Oriented is generic and used for a family of related ideas, rather than being a single neat idea. But the PRESTO idea is that the public URLs should reflect an object-oriented modeling of the data and systems, and that you should have URLs for every object in your system even if there is no satisfactory representation of that resource.
Wikipedia says that an object can be viewed as an independent little machine with a distinct role or responsibility which is a good start, but I have always thought a key value is objects was that they can help model the system according to concepts according the users/developer's/domain's mind or usage. The aspects of being an object that PRESTO is interested in are encapsulation (the idea that entities should be self contained, with data and methods tightly coupled) and introspection (the idea that you can ask an object about its contents: methods, children, etc.). [UPDATE: Oi! NOT INHERITANCE, NOT RPC, NOT INTERFACES, NOT COUPLING STATE, NOT POLYMORPHISM] Bjarne Stroustrup has commented recently that problems which can be composed into a hierarchy are good candidates for Object-Oriented solutions (sorry, no reference here: it was in a Linux magazine I was reading today, maybe Linux Developer...has a Sun Solaris distro on the DVD.)
In pattern terms, PRESTO is a Facade pattern applied to URLs. In terms of UML, we might see PRESTO as saying that public-facing URLs should be constructed based on some entity analysis such as Use Cases or Package Models.
But the key way to think about it is just basic object concepts. The PRESTO approach says to form URLs so that each "directory" in the URL is an object, and its contents are sub-objects, data or other resources. Methods are not expressed as queries, but declaratively by identifying their result: so you don't say
http://www.eg.com/documents/graphicwhich then allows you to say
http://www.eg.com/documents/graphic/titleand so on.
Of course there are often many alternative ways of organizing or categorizing data. Which is why you appeal to use cases to guide you in which the best form is. Indeed, you might have alternative PRESTO URLs for the same data resource.
One piece of software that is highly useful for implementing a PRESTO system is the Tuckey UrlRewrtieFilter which is good for Java-based web servers. We are finding that Rregex-based URL mapping makes the whole thing quite easy and painless, in particular when retrofitting a PRESTO facade on top of an existing web site. The difficulty is largely where it belongs: in figuring out which objects are most interesting or obvious to the users. This is where modeling the particular Use Cases or even Configuration Items comes in.
I think this goes directly against the concept of REST being an architectural style of expressing state by transferring representations between hosts. You have focused on the URL construct and ignored "hypermedia as the engine of application state" aspects of REST.
Ron: Sorry, I have not expressed myself well, obviously. Reducing the API to simple GET/PUT/POST of representations requires that each possible object of interest is treated as a first-class resource, with its own unique and adequate URI. This *corollary* of REST is where PRESTO starts: instead of having functions, we have resources; instead of methods we have resources (being the reified results of what we would otherwise consider a method) hierarchically arranged under their parent object. There is no aspect of message passing that is part of PRESTO that I am aware of.
From my point of view, REST is in several aspects correct and in many wrong. Where its correct and where it is wrong:
* it tries to move from standard WS approach (one uri with many functions) to object oriented approach (everything is an object, erm. a "resource") which is very good idea
* Mr. Fielding probably thinks that get, put, post, delete should be enough to implement any object(resource) functionality (which is of course wrong), eg. deleteUser(int userId, bool backupUserDataFirst) is almost impossible to do in REST
* REST mixes API definition (how the API should look like) with implementation (stateless) and WWW specifics (HTTP)
* REST actually uses object oriented expressions (polymorphism) but prentends to be OOP