- From: Champion, Mike <Mike.Champion@SoftwareAG-USA.com>
- Date: Sat, 4 Jan 2003 16:08:51 -0700
- To: www-ws-arch@w3.org
> -----Original Message----- > From: Mark Baker [mailto:distobj@acm.org] > Sent: Saturday, January 04, 2003 5:30 PM > To: www-ws-arch@w3.org > Subject: REST; good for humans and machines > > > > That REST was believed for humans is, as I understand it, why Web > services were created in the first place. If it's also for machines, > then what we've got here is two ways of solving the same problems. What's the other way ... certainly you're not lumping all things non-RESTful into one category? There would appear to be a myriad of ways of solving the same problem. > > At the very least, this should come as a surprise to the WSAWG, no? > Thoughts? Uhh, maybe a year ago this would have surprised many of us. The REST meme is in pretty wide circulation now. I think we're also coming to an understanding that the "REST is for humans" thing is a red herring; the question of how one imputes the semantics of a web page or web service invocation is orthogonal to the question of the architectural style. Still, somehow or other the contents of a message have to be mapped onto something that a machine can understand. The "classic" SOAP/WSDL paradigm does this more or less mechanically, trusting some human programmer to make sure that the functions and arguments "mean" the same thing on both ends. REST, AFAIK, simply says nothing at all about this. I think it's pretty clear to most who have followed the "REST vs whatever the alternative is" megathread that one can build a RESTful solution to just about any distributed computing design problem. One can also (I think) built an RPC, or asynch document messaging, or tuple space, etc. etc. etc. solution to just about any distributed computing design problem. This leaves us with a number of questions that don't seem to have clear answers at the moment: - Which of these is most likely to be optimal under different scenarios (different networking environments, user requirements, assumptions about homogeneity, availability of out-of-band discovery mechanisms ....)? - How can we conceive of the components and interrelationships in a web services architecture that allows various features to be re-used in different applications with different architectural styles?
Received on Saturday, 4 January 2003 18:09:25 UTC