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

Re: [rest-discuss] Querying with POST

Expand Messages
  • Roy T. Fielding
    ... 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
    Message 1 of 73 , Oct 19, 2004
    • 0 Attachment
      >> 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. 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 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.

      ....Roy
    • 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.