- From: Mark Baker <distobj@acm.org>
- Date: Fri, 11 Oct 2002 14:03:00 -0400
- To: "Cutler, Roger (RogerCutler)" <RogerCutler@ChevronTexaco.com>
- Cc: "'www-ws-arch@w3.org'" <www-ws-arch@w3.org>
Hi Roger, On Thu, Oct 10, 2002 at 06:47:12PM -0700, Cutler, Roger (RogerCutler) wrote: > Mark -- > > One of your responses to my posted question about objects in web services > has gotten me thinking about something else. I am by no means confident > that this makes any sense, but let me give it a shot anyway: > > It seems to me that one of the major points of difference between the REST > folks and others that are less easy to characterize with one word has to do > with verbs. The web services folk are putting them into XML as data and the > REST folk would prefer to have a limited set of verbs on which there is more > or less universal consensus. > > Would it be helpful if the Web Services architecture specified in some way > that the list of verbs that are understood by a web service can be, or > should be, semantically described via RDF in metadata that enhances the WSDL > decription of the service? You could certainly try. And what you'd find by doing so would be quite interesting. But IMO, I don't think it would be helpful for deploying Web services. RDF is only good at relating things, for example describing tennis shoes in terms of regular shoes, or baseballs in terms of balls. For methods, it works the same way; you need some other methods to compare them to. Now, in order to keep these methods manageable (because they need to be deployed a priori), what you would find yourself doing is generalizing them as I previously described[1]. So for example, if the method was "getStockQuote", you could use RDF to compare it to the meaning of "getQuote". But since deploying the meaning of any new method on the Internet is expensive, it's more economical to just compare "getStockQuote" to "GET", since it's more general and therefore the advantages of deployment are spread out over more services (greater network effects). Now, once you've gone through the generalization exercise, you realize that you don't need more specific methods than the base methods you've identified, because you can use these base methods in HTTP to construct messages that can accomplish the same tasks that the finer grained methods were. Thanks for trying to find a middle ground here, Roger, I appreciate it. But unfortunately, there really isn't one (well, outside of using Web services in a RESTful manner). [1] http://lists.w3.org/Archives/Public/www-ws-arch/2002Jun/0085 MB -- Mark Baker, CTO, Idokorro Mobile. Ottawa, Ontario, CANADA. http://www.markbaker.ca http://www.idokorro.com
Received on Friday, 11 October 2002 14:01:49 UTC