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. 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. 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. 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). 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
