RE: FW: draft findings on Unsafe Methods (whenToUseGet-7)

Paul Prescod wrote:
>
> We're getting off into a diversion. Can we agree that every piece of
> information available on the Web should be URL addressable or a PART of
> a URL-addressable resource? And I don't mean part in a vague sense: I
> mean you download a representation and the piece of information is in
> there. In many content-types you can also directly link to
> "sub-resources" of the resource (e.g. XML, PowerPoint, PDF)
>

Agreed. In the case of a Web service, if you perform a simple GET on the
resource, you receive a service description, which tells you how to (a) how
to invoke the service or (b) how to send a message to the service.

> > I've never made the claim that the current UDDI API is better than other
> > approaches. (I can think of many better mechanisms to perform
> discovery.)
>
> No, I'm not talking about better ways to perform discovery. I'm talking
> about better ways to express the *existing API*. i.e. we can improve it
> with *no new ideas* just by recasting it in terms of URIs. Same for
> Google. Same for any other SOAP API you can mention. If you care about
> technology then it should worry you that less flexible and powerful
> services are being unleashed on the world just to be "SOAP compliant".

I encourage you to explore new ways to perform discovery. I would say that
we haven't devised an effective discovery mechanism. Please keep in mind
these basic requirements:
- there as standard APIs/schemas (service types) being developed for certain
types of interactions, and you want to be able to associate individual
service implementations that support these standard APIs/schemas and
discover service implementations based on their service type.
- you want a mechanism to categorize business and services, and to search
based on these categories. (think of this requirement as the ability to
compose smart bookmarks that I can make available to other users)

Right now the most popular form of discovery of Web resources by humans is
Google, although Google doesn't particular help you discover Web services (a
very specialized form of Web resource). Google (until now) hasn't been
particularly available to application (non-human)clients. By building a SOAP
API to Google, applications can now invoke Google searches. I would
characterize the Google SOAP API as extremely flexible and powerful -- so
I'm having trouble following your argument. Are you saying that it could be
more flexible and powerful (i.e., support simpler discovery) if Google
designed a API based on something else other than SOAP?

If you spend a moment looking at the Google WSDL description, you'll realize
that the input and output messages are relatively complex. The data are
structured and typed, and the formats change based on the function you're
performing. From a developer's point of view, it much simpler to deal with
these input and output messages as application structures than as URI
constructs. I'm not sure that I'm willing to sacrifice developer
productivity for a simpler discovery mechanism. I'm willing to explore the
concept further as part of a research project on the next generation of Web
services -- but I'm not willing to disrupt our current set of technologies.

If a WSDL document is by convention available thru GET from every Web
service URL, why can search engines use this information for discovery?

> Forget REST. Concentrate on Web architecture. One of the principles is
> that as many things as reasonably possible should have URIs:
>
> "The essential process in webizing is to take a system which is designed
> as a closed world, and then ask what happens when it is considered as
> part of an open world. Practically, this effect on a computer language
> is to replace the names/tokens/identifiers for URIs. Thus, where before
> reference could only be made to something in the same
> document/program/module one can with equal ease make reference to
> something in a different one somewhere in that abstract space which is
> the Web."

Since Web services by definition are identified by a URI, you can easily
reference a Web service. Our are you looking for more granularity -- I
imagine that you're asking for a mechanism to supply a URI that provides
access to a specific method within the service?
There are ways to do so. You could provide a reference to a specific QName
(referencing an operation within a portType) within the WSDL document.

Anne

Received on Tuesday, 23 April 2002 08:35:13 UTC