On Dec 8, 2006, at 9:41 PM, Steve Jones wrote: > > > > 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.
I have no idea what you might mean here. The WS-* universe has built its own protocol stack that can be used on top of some others (without really sucessfully hiding their details). REST is an abstract architectural style, the most popular implementation is the HTTP/URI protocol stack. What's this difference you're referring to? > 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. I don't understand your point (again). The main benefit (if you want to call it that) is that you can generate code from a WSDL. (We both agree that it's not really a benefit, but that's beside the point.) If code generation is not the use case, the difference is that WS-* has WSDL and REST does not have anything comparable that is machine- processable yet. If you want to, you can claim that this is a disadvantage, but it's unreasonable to claim that you can't make things work without a machine-readable description language. > 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). That's not a claim, but a fundamental principle - URIs identify resources as the general case. Here's an example resource identifier to convince you: http://www.amazon.com/Enterprise-Adoption-Strategies-Steve-Jones/dp/ 1847283985 > > I thought I understood REST until this thread started! Can you separate your questions about REST from your criticism of it? I have a feeling that's the major source of confusion here. Stefan -- Stefan Tilkov, http://www.innoq.com/blog/st/
