On 08/12/06, Andrew S. Townley <[EMAIL PROTECTED]> wrote: > > > > > > > On Wed, 2006-12-06 at 21:56, Stefan Tilkov wrote: > > > So should REST URIs have meaning or are they opaque? > > > > > REST does not require them to be opaque, but basically forbids you to > > rely on any meaning they might have (or can be interpreted to forbid > > that, depending on whom you ask). > > I've been waiting for someone who saw a similar discussion over on > rest-discuss recently to jump in with what is, I think, a critical part > of this discussion, but since nobody did, I'll give it a go: > > My impression about the opacity of a URI in REST is totally about the > context. I can't remember who pointed this out on the other list, but > from the client's perspective, the URI should be opaque. It should > *somehow* understand what traversing the URI should mean, e.g. it was > provided as a hyperlink or in an HTTP Location header in response to a > POST request.
opaque means that URIs should be meaningless, so all sensibly named URIs are therefore not REST. > > For the server, however, opacity is totally not the case. It is fully > in control of what the URI means and how it should be interpreted (it > defines the naming scheme, cool URL's shouldn't change and all that). > > I think there is a third point here that Stefan mentioned about humans > using the URI which is important, but I also think that the state > machine part of REST still plays here. You may have an easy to remember > URI naming scheme for initially interacting with the site or the > service, but from then on, if I understand correctly, you are > interacting with the application in a service-specific state machine > which should only be based on understanding of the information exchanged > with the server. But if its easy to remember then its not opaque (even sensible + GUID isn't opaque). > > If the client receives a response to a GET with hyperlinks and > *understands* what a hyperlink is supposed to do, it can follow this > link if necessary to get more information. An example for this would be > an XML document for an invoice with an XLink reference to a purchase > order sitting somewhere on the same or even totally different system. > If you want to see the purchase order, you just dereference the link, > and presto, purchase order revealed. But how does the client understand what those hyperlinks mean? So the invoice to PO reference for instance, how do I know that it is a PO? > > This goes back to some of what I was trying to point out about > separation of concerns. REST provides a uniform interface for > interacting with a service, the the interaction and semantics of what > the service actually does must be described separately (unless you're > dealing with something which can be self contained like HTML > applications in the sense that you know what the meaning of the > information you get is based on a single specfication). REST (IMO) does not provide a uniform interface for interaction, it provides a uniform interface for invocation, and there is a big different. > > This is why I think the MEST guys felt the need to create SSDL[1] to > describe how to interact with uniform SOAP interfaces through > ProcessMessage. > > I don't believe that REST alone is enough to make meaningful > applications. Even the Web isn't REST alone. It's REST+HTML+HTML > Forms. The clients (Web browsers) understand what those specifications > mean, and those specifications define a "get out clause" in the form of > the content negotiation capabilities to allow things like PDFs to be a > part of the modern Web. > > Unless you have this additional layer of meaning on top of REST (even > APP[2] is a REST application, in my view), REST is not going to be the > solution to your problem. REST is an architectural *style* not a > physical architecture. > > I think this is the point where Stefan, Jan and Steve are struggling > with. If you want to get to the bottom of this, everyone's going to > have to start saying what their assumptions about how things work really > are, because there's at least 60% of the conversation occurring based on > how people implicitly see the whole system fitting together. > > ast > > [1] http://www.ssdl.org/ > [2] http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-11.txt > -- > Andrew S. Townley <[EMAIL PROTECTED]> > http://atownley.org > >
