Re: [rest-discuss] Querying with POST
- On Tue, Oct 19, 2004 at 10:16:27AM -0700, Roy T. Fielding wrote:
> >>That is, we have GET, PUT, POST and DELETE, our fundamentalI don't think you've read the whole discussion, Roy, because that's
> >>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
> Nonsense, Mark. Of course that is REST -- it is right in the
> 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.
part of my point.
Would it have helped if I clarified that from the server's POV, it's
RESTful since uniform semantics are *provided*, but from the client's
it isn't since uniform semantics aren't *expected*? Or are you saying
that REST doesn't constrain the client end of connectors? That wouldn't
make much sense to me.
> >Sometimes it's hard to see the forest for the trees here. I've foundAy carumba, I see I described substitution in terms of implementation.
> >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.
> Sorry, that makes no sense. The interface is substitutable. Resources
> 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.
My bad. But my point remains; that RESTfully, resources cannot be
expected to process, say, XQuery documents and return the results of the
specified query in the POST response, or in the form of another
resource, or anyplace else for that matter, since providing such an
expectation is not uniform.
Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
- 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 :-)