[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Service discovery
"Bullard, Claude L (Len)" wrote: > > Ok. That was actually how I thought things > worked originally until we got into this thread. > I might still need the registry for further > processes of discovery, but not necessarily for > drilling into one I've identified as a candidate. Right. But what differentiates me from the UDDI people is that I see the registry as only something a human being is interested in. Which means it is a web site, not some kind of rigidly standardized service (whether standardized using REST or RPC, doesn't matter). > Now, you posted this excellent set of points. > If we concentrate on this list, I may achieve > REST satori. > > "REST is defined by four interface constraints: > > 1. identification of resources; > > 2. manipulation of resources through representations;* > > 3. self-descriptive messages; > > 4. hypermedia as the engine of application state." > > Please help me understand how each of these are > defined in your use of the web technologies vs > what the web service API method advocates define. 1. identification of resources; I claim that Microsoft's stock quote's from last year are a resource and should have a URI. http://chart.yahoo.com/k?a=11&b=12&c=01&d=02&e=13&f=02&g=d&s=MSFT&y=0&z= They could obviously use more human-readable parameter names but I don't control that particular service. Let's say ideally it would be more like: http://chart.yahoo.com/k?quote=MSFT&start-date=...&end-date=... I further claim that insofar as it does already have a URI it would make sense to turn it into a "web service" merely by returning XML instead of HTML to people who pay for that privilege. To get this across a network you do: GET /k?quote=MSFT&start-date=...&end-date=... host: chart.yahoo.com That's all. The RPC way of doing the same thing is to NOT identify this resource as a resource (something that can be referenced, hyperlinked to, RDF-asserted, etc.) and rather balkanize the "address" into parameters of the form: GET /RPC-endpoint host:chart.yahoo.com <10 lines of SOAP invocatoins> <parameters> <name>MSFT</name> <start-date>...</start-date> <end-date>...</end-date> </parameters> Now I can't reference it, can't hyperlink to it, can't RDF-assert to it, etc. 2. manipulation of resources through representations; Given that RPC doesn't have any notion of resources, it surely can't have any notion of representations of resources. This point is Roy's way of saying that HTTP is not a global file system, despite what some people may think. Resources are not files. As we discussed in the other thread, Len Bullard is a perfectly fine resource. Your representation on the Internet may be in HTML ... or not. 3. self-descriptive messages; Both groups use XML to try to make messages self-descriptive. But the HTTP messages are in many ways MORE self-descriptive because they use a public namespace. You don't need any extra information to figure out how to get a particular stock quote other than the URI. In the RPC version you need the URI *and* enough information to regenerate the XML. Anyone looking at the HTTP version (especially a firewall admin) knows that as long as the software inside the firewall is not broken there is NO WAY that there can be any bad side effects because HTTP GETs are defined to be safe and side-effect-free. 4. hypermedia as the engine of application state; If I want to incorporate some portion of Microsoft's stock quote from last year into another XML document I can use XPath and XLink or XInclude. I can use hypermedia to build a compound service that combines information from various sources. I can't do that with RPC. If this were a more transactional application where the server was keeping information for me (e.g. my plane reservations) then I would expect the server to generate NEW URIs for me so that I could refer to them when I want to get access to that state again. i.e. I would use addresses and hyperlinks to recover my server side state. For instance if I switched client-side devices or if I wanted to bring a third or fourth party into the transaction. Paul Prescod
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|