On Fri, 2006-12-08 at 15:27, Steve Jones wrote: > On 08/12/06, Andrew S. Townley <[EMAIL PROTECTED]> wrote: > > 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.
No, it doesn't. A good friend of mine told me once how to order my favorite Thai dish in Thai at a restaurant. I don't know what the words mean exactly or how their spelled, but I know that I'm normally going to get something quite tasty if I pronounce it reasonably close. I just need to know how to make the sounds, not what the sounds mean. The sounds are (hopefully) meaningful to someone from Thailand at the restaurant, but they'd be meaningless if I tried it at a Tandoori place. This is what I was trying to say about perspective and context. The client just has a string of bytes that it uses to request things from the server. The *what* is being requested (or possible variations of the value) is agreed outside the scope of the immediate interaction. Even with HTML, you don't know you've got a form in it until you parse the message. If you can support forms, great. If you can't, well, then that's possibly a problem, but it's also possibly one way to have a flexible interface that allows clients of different capabilities to consume the same messages. In some ways, this is similar to the use of mustUnderstand or xsd:any, but, I agree, it is more generic and less formalized than WSDL. So what? > > > > 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). You aren't separating your perspectives. If it is sensible to the server, it may *look* sensible to the client, but the client can't make any assumptions about the values beyond what has been otherwise formally specified, e.g. ?foo=123&bar=fido are query parameters to a GET request because that's a part of the underlying definition of URI [1]. If you were walking down the street and saw the word 'read' on a piece of paper, would you know what it meant? You couldn't without knowing the context in which it was being used. URIs in REST are the same sort of deal. What I was talking about was the difference between: www.saashost.com/someservice/ and www.saashost.com/someservice/resourcetree/resource1?accountId=AA4413988cx123 The one you're likely to remember or need to type in is the first one, but you could certainly expect to get something like the second one during the interaction with the service. Either one would should be suitable to copy and paste into an email and send to someone else. What they did for them may not be the same as what they did for you if they don't have the appropriate security credentials, for example. > > > > 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? Because your service interface description says what they mean. It seems to me you're expecting automagic code generation of client proxies for REST services because that's what you can do with WSDL. I don't think that's a reasonable expectation to have. Even in WSDL, you don't have any way of knowing what the method calls actually mean or in which order you should call them as has already been mentioned before within this thread. > > > > 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. Ok, you're right. I was in a hurry and ended up being imprecise. REST has a uniform invocation mechanism which allows you to concentrate on the messages and data being exchanged between the client and the server and *not* on which method needs to be called. Your interaction is based on where you are in a given message exchange relating to the messages sent and received from a given URI. What this buys you is that you can focus on the messages and not the invocation, because the invocation mechanism should be the same across all of the servers you should want to talk to. As has also been said in this thread, it boils down to which parts of the overall solution need to be the most independent to allow your architecture to evolve sensibly over time. I believe that if you have a clean separation between invocation and interaction (as you said, they are different), you will ultimately have more flexibility than if they are closely tied together. I think that WSDL+SOAP end up tying these things too closely together. Yes, it allows you to easily generate proxy client stubs (a good thing since every service endpoint is likely going to be different), but if you have something that acts as a gateway (PEAA) with at least GET, PUT, POST, DELETE to provide a uniform communications channel. Any service you crate uses the same gateway implementation, but the real work of the service then becomes focused on the URI and the message. In any event, doing something useful with that message is going to mean writing code anway, but it'll be code that's not tied to a particular remote object interface, only the messages and the business-level exchange protocol of the service. ast [1] http://www.ietf.org/rfc/rfc2396.txt -- Andrew S. Townley <[EMAIL PROTECTED]> http://atownley.org
