RE: List of outstanding issues regarding the RPC proposal

> 
> Concern:  Is it appropriate to do RPC as a "chameleon" 
> binding to HTTP?
> 
> Proposed resolution: I don't think we have consensus, but for several
> reasons I propose that we do retain RPC, in a manner based on 
> my proposal.

Agree, for the reasons Noah cites.

> 
> Concern:  Should the RPC convention support HTTP PUT?
> Proposed resolution: no.  

Agree.

> 
> Concern:  My proposal declines to establish a specific convention for
> mapping resource-identifying RPC arguments into URI's. 

> Proposed resolution:  either stick with my original proposal 
> to provide a specific URI mapping, or provide a non-normative appendix 
> explaining at least one convention that might be used with HTTP URIs. 

I like the "non normative appendix" idea.  We can't hold up
SOAP 1.2 for this, and clearly it is going to be non-trivial to get the
details right.  But putting what we do have out there to bootstrap
experimentation is a Good Thing, and standardization will have to wait for
more experience.  Internationalization can be an open issue, IMHO, so long
as the basic concept is proved in the appendix.  My original objection was
to deferring the convention to a different architectural level than SOAP
(e.g., in WSDL), which would complicate interop.  I'm fine with saying "the
convention should be associated with SOAP, eventually, but we can't do this
in the 1.2 timeframe."  


> Concern: My proposal did not explicitly describe use of MEPs.
> Proposed resolution: it was always my intention that POST 
> would continue to use the request/response MEP, while GET would use the 
> newly-hatched one-way pull (which I still think should be renamed). 

I don't have a strong opinion, or maybe I don't understand the issue
very well.  I don't see how an RPC call to invoke an safe procedure (maybe
we could be non-OO and talk about RPC "procedures" to distinguish them from
HTTP methods, even if the procedure being invoked is really a method on an
object) is a different MEP if it is bound to GET and the arguments encoded
in the URI than if it the arguments are encoded in SOAP and POSTed.  I had
thought that the "one way pull" idea was a way of shoehorning GET into the
transport binding framework, but we seem to be backing away from the idea
that the GET somehow transports an empty SOAP message.  Anyway, I'm just
registering my confusion, not agreement or disagreement with any particular
proposal.  Maybe the options and rationales could be clarified a bit?


> One remaining  question is how to determine whether the HTTP 
> method should be GET or POST?  ... an alternative that would be more
> scalable would be to introduce a new feature -- call it "REST 
> method" 

I think I like this better than tying it to the MEP.

> 
>  I  believe the path of least resistance at the moment is to drop the
mention 
> of both PUT and constructors, and leave it to applications to decide how
most
> appropriately to use of facilities that we provide.  

Agree

Received on Monday, 3 June 2002 11:40:07 UTC