Re: [getf] Proposal for Web-friendly representation of RPC's in SOAP

Noah,

I think this is really quite good.  I have reservations about this
approach, but I agree that what you have here is probably the best that
can be done with it.

For example, by focusing on the methods that already exist, like
"getQuantityOnHand( partId )", the resultant granularity of URI will
likely be too fine grained, because RPC is usually quite fine grained.

Using your guidelines below, "getQuantityOnHand( partId )" would map
to a URI like http://foo.org/part/<partId>/quantityOnHand.  As
"quantityOnHand" is just an Integer, that means that the representation
may only be a couple of bytes.

On the other hand, if we just used the URI;

http://foo.org/part/<partId>/

Then a GET could return a full description of the part, perhaps in XML,
of which the quantityOnHand would be one information item in that
representation.  This would certainly be more efficient.

More comments in-line ...

On Wed, May 29, 2002 at 10:04:45AM -0400, noah_mendelsohn@us.ibm.com wrote:
> * When performing a resource creation the method name carried as the
> immediate child of the SOAP body element is interpreted as the name of a
> constructor.  In other words, the method name describes the means by which
> the arguments are used to create the resource.  When using the HTTP binding
> provided by this specification, resource creation should be performed using
> the HTTP PUT operation.

Is there any particular reason why the method/constructor needs to be
there at all?

It is quite useful to be able to GET a representation, make a change,
and then PUT it back.  If what was received on a GET did not have
this "constructor", and it was attempted to be PUT back, would that
work?  It doesn't sound like to would.

> * When doing a partial update or creating a sub resource, the method name
> carried in the SOAP body conveys the nature of the update to be performed,
> and the interpretation of the arguments.  When using the HTTP binding
> provided by this specification, partial updates and/or sub-resource
> creation should be performed using the HTTP POST operation.

Is this done without any a priori knowledge of the resource?  i.e. is
the method name authoritative about the action that is taken?  If so,
then this is still tunneling.  But perhaps you didn't intend to remove
tunneling altogether?

> NOTE:
> In general, this specification concerns itself with the creation and
> processing of SOAP envelopes, and does not formally constrain the means by
> which RPC or non-RPC URIs are constructed for use with SOAP.   Thus, no
> standard means of mapping resource-identifying arguments or method names to
> URIs is provided herein;

Excellent.

> it is anticipated that such conventions would be
> developed in conjunction with the creation of Web service description
> languages, language bindings, and so on.

Hmm, I would say that any standardized URI conventions are a bad idea,
as they break opacity;

http://www.w3.org/DesignIssues/Axioms.html#opaque

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@acm.org
http://www.markbaker.ca        http://www.idokorro.com

Received on Wednesday, 29 May 2002 14:45:58 UTC