[
Lists Home |
Date Index |
Thread Index
]
"Bullard, Claude L (Len)" wrote:
>
>...
>
> 1. Names. GUIDs vs URIs.
Actually, GUIDs are a lot less noxious then the kinds of identifiers
that are even more implicit.
Microsoft.GetPerson("Bullard", "Len")
IBM.GetPerson("Len", "Bullard")
Since I can't link to these things I can't even use RDF to assert that
they are really the same guy.
> 2. Where to put the names (in the URI, in the SOAP message)
Agree.
> 3. HTTP has all the methods we need if we just used them
> correctly and could accomodate complex (say rich) actions
> if we ganged them correctly (I don't know how this
> can be proven.) vs we need specific API calls that enable
> us to discover a business exists, is of a given type, can offer
> typed services based on public or privately negotiated document
> types
I don't know why you're mixing discovery into this point about method
names. If a great discovery mechanism works for SOAP RPC it will work
for HTTP. The only question is whether to use publicly shared, generic
method names defined by HTTP or locally defined ones through RPC. UDDI,
if it works, might still be a great way to find all HTTP providers of
service X. But instead of the UDDI describing some API they support it
would probably say that they support some XML vocabular(ies) and means
of GET/PUT/POSTing and DELETing XML documents conforming to those
vocabularies.
> A URI is a name and a locator. A URI can have arguments
> appended to the end of it, so it is a hyperlink and a function call
> (which after a lot of years I've come to believe are the same thing
> but we can argue about that).
You can only call it a function call if you discard function calls with
"dangerous" (i.e. almost any) side effects.
> ... A URI is supported ubiquitously, so
> web services comes down not to a lot of new technology but to applying
> what we already have.
Exactamundo.
Paul Prescod
|
