One question that comes up really regularly when I have been yacking about the PRESTO approach with people over the last month, is that people don’t see how Objects fit into it. They get Persistent URIs, they get REST, but the Object part is not so obvious. (Actually, I have had several people email me that they approach is one they have been tending towards in their work too.)
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/document/?getGraphic but http://www.eg.com/documents/graphic which then allows you to say http://www.eg.com/documents/graphic/title and 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.
Constructing "cool" URIs for things is a Good Thing, but object orientation is primarily about message passing (in the Smalltalk sense) and/or inheritance and polymorphism (in the Java/C++ sense). I don't see how an object, which tends to have minimal exposed information and numerous methods, maps to the REST style, with representations having copious information/state and minimal methods for transferring it.
In short, the URI hierarchy that you are proposing is fine as an idea, but URIs themselves are not particularly important to REST as a concept. Similarly, mapping objects' instance variables to other URIs may also be useful, but why not just transfer their representation as part of a GET/PUT/POST of the object itself.
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.
I do not agree that object orientation is primarily about message passing, inheritance and polymorphism. Certainly these are characteristics of many object systems (Smalltalk as you mention), but not definitive of them (C++ didn't start with message passing for example). The core distinctive of OO are *objects*: the tight coupling of data and methods, and for PRESTO the methods are exposed by the resources that result from them not as functions. I am certainly aware that using "Object" is problematic (and I did explicitly limit it to encapsulation and introspection above), but while there are names for systems that use message passing but not objects (e.g. "message passing systems") and polymorphism without objects (e.g. ad hoc polymophism) and inheritance without objects (e.g. XML schemas) there is no name for Objects just meaning simple objects. Perhaps ADA "generics" are something closer, but still not adequate.
Since PRESTO has no methods, there is no polymorphism (though something could be made); and since PRESTO has no classes there is no inheritance (though something could be made.)
The rationale for PRESTO is that while REST may express all sorts of useful web-characteristic systems, there are many general guidelines floating about (e.g. TBL's "Cool URLs don't change") which really do warrant solidifying into a methodology so that we can figure out which
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
So generally REST is a nice try, can be used to public some objects(resources) on the Web, but its principally a mixed bag of "Web best principles" and some "innovative" ideas.