Re: Issue 133, and permitting no body

By the way, I realize that in drafting my multiply example, the text also 
talks about square roots.  There's nothing subtle there:  I was first 
going to discuss square root, then thought multiply would be a bit better. 
 I realize now that I missed a few places where the prose still says 
square root.  There's nothing subtle intended there.   Just in case, here 
is the corrected text:

=================================================================


While certainly not an expert, I think I understand the basics of REST and 

its advantages as discussed in this thread.  I particularly understand 
it's applicability to the many situations in which there are stateful 
resources, and a desire to create/update/access them in a consistent 
manner.  I think I'm mostly happy with where this discussion is drifting, 
but there's one aspect I don't feel I've quite grok'd. 

The aspect of SOAP/Rest convergence that I'm still wrestling with seems to 

come from my perspective that what we're building with SOAP is very often 
a "Web Service".  So, the resource that's at the other end of the URI 
isn't a bucket of bits or properties, it's a service.  Example:  let's say 

I want to put out on the Web a "service" that multiplies numbers. Since 
everything on the Web is a resource, that service is a resource, and is 
accessible using a URI.  Probably no disagreement there?

Now, if I want to ask that resource to multiply two numbers, I am neither 
permanently updating the resource, nor querying its dynamic state (its 
state is not dynamic).  It only _has_ state, I.e. is distinct from other 
resources, in the limited sense that it's been programmed to 
multiply.  If I were to send it new code to do division instead of 
multiplication that would be a PUT to update its state, I think, but 
that's not the case that interests me.   I just want to send it numbers 
and get back square roots.

I really am not sure how REST would approach this, with or without SOAP. 
Certainly, the multiply operation is idempotent, makes no persistent 
changes to the state of the resource, and has results that one might wish 
to cache.  The cacheability suggests to me that GET would be appropriate, 
but I'm curious how REST would approach this?

What I _think_ one would typically do with HTTP independent of SOAP would 
be something like sending a GET to:

        http://numbers.com/multiply?inputnumber1="3"+inputnumber2="4"

implying that all the products represent one parameterized resource. Now, 
consider the following SOAP:

        <s:envelope xmlns:s="...soap env uri...">
                <s:body>
                        <multiply xmlns="...math namespace...">
                                <inputnumber1>3</inputnumber1>
                                <inputnumber2>4</inputnumbe2>
                        </multiply>
                </s:body>
        </s:envelope>

An obvious binding would be:

 
http://numbers.com/?operation="multiply"+inputnumber1="3"+inputnumber2="4"

A trickier binding that might be viewed as more restful, but which is also 

allowed by the current SOAP framework would be:

        http://numbers.com/multiply?inputnumber1="3"+inputnumber2="4"

in which the operation is encoded in the resource name, not the parameter. 

   Note that this one is identical to the one suggested before we even 
looked at SOAP.  How do either of these look from a REST point of view?

Anyway, to net it out, my concerns in this note are:

1) to point out that in many cases, it is the _service_ that is the web 
resource when we're building web services.
2) to ask those who understand REST better than I do how they would model 
such a situation, with or without SOAP

Many thanks.

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------

Received on Wednesday, 6 February 2002 08:06:03 UTC