On 08/12/06, Andrew S. Townley <[EMAIL PROTECTED]> wrote: > > > > > > > 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.
You do actually know what the sounds mean (to you) as you know it refers to a specific dish. > > 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? I guess I'm an old school engineer, formalism is a good thing, formalism reduces costs due to miscommunication, formalism enables things to be defined up front. If I am agreeing approaches and interfaces between 9 different parties then I want something formal that is at least partly binding rather than 9 different approaches which are all informal. > > > > > > > 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]. And here is where I have to disagree, people make assumptions, that is what people do, its one of the real advantages of people over computers. If you present information to people in a URI they will make assumptions as to what it means and what they can do (hell who hasn't edited a URI in a browser window to "shortcut" a search or something?) In terms of "formally specified" what is the standard approach for making that formal communication in REST? > > 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. I'd make an assumption that I was looking at some sort of advert (as in READ THIS! IT WILL CHANGE YOUR LIFE). People make assumptions, its normal, having an IT approach that ignores how people actually work is very dangerous. > > 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. And if I had two accounts and the ID of the first one was 13988 and the second one was 14933 I'd make a guess at switching the numbers around in the URI. Something might break, but I'd give it a shot. This all sorts of indicates that GET isn't the right choice for REST and that POST would have been better because at least then the URI would be fixed while the content would change. > > > > > > > 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. What is the standard service interface description language for REST? > 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. Again if they have sensible names people will make assumptions, the better the names the better the quality of the assumptions. Hell you could supply some example BPELs or WS-Choreography to indicate the preferred order if you wanted. Expecting to not have to work at the protocol level and to work at the application level is NOT IMO an unreasonable expectation in 2006. Still having people shoving ASCII/Unicode down ports doesn't sound like we have move forwards much in the last 30 years. > > > > > > > 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. But you need a formal way of description the interaction, which is what I'm asking... what is the standard way of describing interaction in REST? > > 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. That is a bold statement IMO, given that SOAP/WSDL (unlike REST) isn't limited to a single protocol stack. It could be argued that the WSDL should be split into two documents, but there are clear sections (IMO) around invocation and interaction. > 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. A decent WS-* implementation isn't bound to a remote object... and here I get confused again. Firstly to claim that rest is working at the exchange level (rather than invocation level) you have to have a way of describing that. Secondly there have been claims that a REST URI refers to a specific resource instance, thus implying a close binding to a specific object instance (not just a class). I thought I understood REST until this thread started! > > ast > > [1] http://www.ietf.org/rfc/rfc2396.txt > -- > Andrew S. Townley <[EMAIL PROTECTED]> > http://atownley.org > >
