[
Lists Home |
Date Index |
Thread Index
]
"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
|
