Re: [rest-discuss] Querying with POST
>> That is, we have GET, PUT, POST and DELETE, our fundamentalNonsense, Mark. Of course that is REST -- it is right in the
>> ways of dereferencing a URI. We'll assume that we are putting
>> together nice RESTful services and using all these methods correctly.
>> What happens when we start combining these dereferences?
>> For example:
>> POST is used to create new resources
>> GET is used to retrieve a representation of a resource
>> On their own they're RESTful,
> No, the POST invocation isn't RESTful by itself. In the examples
> people have given, the client expects that a particular POST invocation
> will result in a resource being created (and furthermore, that this
> resource will have a particular relationship to the POSTed
HTTP standard. The client is *told* by the server the URI of
the new resource. The client doesn't need any other expectation than
simply following HTTP. This is no different from following application
state as presented by links within representations.
> Sometimes it's hard to see the forest for the trees here. I've foundSorry, that makes no sense. The interface is substitutable. Resources
> helpful to focus on one of the primary objectives of the uniform
> interface; substitutability, i.e. the ability to substitute one service
> implementing POST with another service implementing POST.
> Query-via-POST fails this test because the expectation about the query
> results being returned cannot be provided by other services. For
> example, if one swapped in a resource which spat out the input document
> to a printer, then clearly it wouldn't meet the expectation of
> performing a query.
are not substitutable. Nobody has an expectation that you can replace
one resource with a different resource and have continuation of
semantics. What you get with REST is an interface that tells you
how it works. POST is part of that interface when used right.
- On Wed, 2004-10-27 at 05:32, S. Mike Dierken wrote:
> > > operation. You don't need to 'send a query' - what you typically want toPing. The light went on.
> > > is to 'retrieve results'.
> > Tell me that's not nit-picking please?
> It's not nit-picking.
> > why differentiate?
> Because a 'query' is not /required/ to be different than a retrieval. There
> is no uniqueness to it. It also shifts focus from
> functions/methods/operations to the actual data/information being exchanged.
> Creating uniformity between the two actions allows your systems to work with
> other people's software even if those other people don't know what your
> particular 'query' is supposed to mean. For example, how soon would
> AltaVista or Google assign a developer to build code to support "Dave's
Thanks for that.
> > Go to the shop vs get a newspaper?'Don't care how. Its the newpaper I want.' Yes.
> > Same thing?
> No, the difference is that "go to the shop" is the detailed implementation
> approach, whereas "get a newspaper" is the result regardless of the
> > Good. I'd hate to ask all systems to host server software!<grin/> OK, dream on.
> Oh, but imagine what could be possible if they did!
The server in my fridge is too much for me :-)