Loading ...
Sorry, an error occurred while loading the content.

Re: [rest-discuss] Querying with POST

Expand Messages
  • Mark Baker
    ... I don t think you ve read the whole discussion, Roy, because that s part of my point. Would it have helped if I clarified that from the server s POV, it s
    Message 1 of 73 , Oct 19, 2004
    • 0 Attachment
      On Tue, Oct 19, 2004 at 10:16:27AM -0700, Roy T. Fielding wrote:
      > >>That is, we have GET, PUT, POST and DELETE, our fundamental
      > >>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
      > >representation).
      >
      > 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.

      I don't think you've read the whole discussion, Roy, because that's
      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 found
      > >it
      > >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.

      Ay carumba, I see I described substitution in terms of implementation.
      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.
      --
      Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
    • Dave Pawson
      ... Ping. The light went on. Thanks for that. ... Don t care how. Its the newpaper I want. Yes. ... OK, dream on. The server in my fridge is too much
      Message 73 of 73 , Oct 27, 2004
      • 0 Attachment
        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 to
        > do
        > > > 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
        > Query"?
        Ping. The light went on.
        Thanks for that.



        > > Go to the shop vs get a newspaper?
        > > 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
        > implementation.

        'Don't care how. Its the newpaper I want.' Yes.



        > > Good. I'd hate to ask all systems to host server software!
        > Oh, but imagine what could be possible if they did!

        <grin/> OK, dream on.
        The server in my fridge is too much for me :-)


        --
        Regards DaveP.
        XSLT&Docbook FAQ
        http://www.dpawson.co.uk/xsl
      Your message has been successfully submitted and would be delivered to recipients shortly.