I think we need a REST FAQ.. For the nth time now, URIs can be opaque or not opaque in REST. REST does not say anything about this. All those that think URIs should be opaque should try to resolve that goal with the goal of having all resources have identifiers in the context of HTML FORMs. Either the client creates URIs based on the FORM or the client doesn't create URIs for the (new) resources, all of this at the control of the server. I guess somebody could say that FORMs using GET aren't part of REST, which would be even more obviously wrong. Cheers, Dave
_____ From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Jones Sent: Friday, December 08, 2006 7:28 AM To: [email protected] Subject: Re: [service-orientated-architecture] ROA is not SOA - (was Alternatives to WS Standards) On 08/12/06, Andrew S. Townley <[EMAIL PROTECTED] <mailto:ast%40atownley.org> org> 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. <http://www.ssdl.org/> org/ > [2] http://www.ietf. <http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-11.txt> org/internet-drafts/draft-ietf-atompub-protocol-11.txt > -- > Andrew S. Townley <[EMAIL PROTECTED] <mailto:ast%40atownley.org> org> > http://atownley. <http://atownley.org> org > >
