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

Re: [rest-discuss] Complex queries

Expand Messages
  • Brian Sletten
    ... I don t know that this is any form of a preferred approach, but where possible, I like to turn the query itself into an information resource so that it can
    Message 1 of 9 , Nov 21, 2008
    View Source
    • 0 Attachment
      > I was wondering what the preferred approach to make complex queries
      > over HTTP? I have to provide data in the request body (It could be a
      > xml description or even an image). The request is safe. The response
      > can't be cached since it depends on the request body. Moreover, the
      > URL does not have to be shared. What are the problems of using POST
      > in that situation?
      >
      > Are you aware of any problem with implementations or proxies for GET
      > requests that contains a body?
      >
      I don't know that this is any form of a preferred approach, but where
      possible, I like to turn the query itself into an information resource
      so that it can be shared. You can POST the query into a /query
      information space, get an ID associated with it and then do a GET to /
      query/<id> (or PUT it to a named query). This link can be shared,
      reused, cached, etc. You can also imagine building a query system
      where you can override default (or expected values) as part of the GET
      too:

      GET /query/<id>?custid=1234

      That is potentially cacheable as well.
    • Benoît Fleury
      Thanks for your answers. I read Web Architecture from 50,000 feet [1] and there is an interesting paragraph that may be related to my problem: The
      Message 2 of 9 , Nov 21, 2008
      View Source
      • 0 Attachment
        Thanks for your answers.

        I read "Web Architecture from 50,000 feet" [1] and there is an interesting paragraph that may be related to my problem:

        "The introduction of any other method apart from GET which has no side-effects and is simply a function of the URI is also incorrect, [...]"

        My understanding is that it allows me not having to use GET. It does not say I can use POST but I am going to use POST for practical reasons :)

        [1] http://www.w3.org/DesignIssues/Architecture.html

        Benoit


        2008/11/21 Brian Sletten <brian@...>
        I was wondering what the preferred approach to make complex queries over HTTP? I have to provide data in the request body (It could be a xml description or even an image). The request is safe. The response can't be cached since it depends on the request body. Moreover, the URL does not have to be shared. What are the problems of using POST in that situation?

        Are you aware of any problem with implementations or proxies for GET requests that contains a body?

        I don't know that this is any form of a preferred approach, but where possible, I like to turn the query itself into an information resource so that it can be shared. You can POST the query into a /query information space, get an ID associated with it and then do a GET to /query/<id> (or PUT it to a named query). This link can be shared, reused, cached, etc. You can also imagine building a query system where you can override default (or expected values) as part of the GET too:

        GET /query/<id>?custid=1234

        That is potentially cacheable as well.



      • Julian Reschke
        ... Hard to say, see . Other than that, you may want to look at RFC 5323. BR, Julian
        Message 3 of 9 , Nov 21, 2008
        View Source
        • 0 Attachment
          Benoît Fleury wrote:
          >
          >
          > Hi,
          >
          > I was wondering what the preferred approach to make complex queries over
          > HTTP? I have to provide data in the request body (It could be a xml
          > description or even an image). The request is safe. The response can't
          > be cached since it depends on the request body. Moreover, the URL does
          > not have to be shared. What are the problems of using POST in that
          > situation?
          >
          > Are you aware of any problem with implementations or proxies for GET
          > requests that contains a body?

          Hard to say, see <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/19>.

          Other than that, you may want to look at RFC 5323.

          BR, Julian
        • Aristotle Pagaltzis
          ... Put in a layer of indirection: let people create a “query asset” by POSTing the body data in a separate request, producing a resource whose URI can be
          Message 4 of 9 , Nov 21, 2008
          View Source
          • 0 Attachment
            * Benoît Fleury <benoit.fleury@...> [2008-11-21 19:05]:
            > I was wondering what the preferred approach to make complex
            > queries over HTTP? I have to provide data in the request body
            > (It could be a xml description or even an image). The request
            > is safe.

            Put in a layer of indirection: let people create a “query asset”
            by POSTing the body data in a separate request, producing a
            resource whose URI can be included in the actual query request
            that they then send as a GET.

            > The response can't be cached since it depends on the
            > request body.

            You are begging the question: you gave no reason for why the
            response is inherently uncacheable. The specification of GET
            and POST is not inherent to your problem.

            > Moreover, the URL does not have to be shared.

            Better to engineer for serendipity and not decide this up front.

            Regards,
            --
            Aristotle Pagaltzis // <http://plasmasturm.org/>
          • Barbara Van De Keer
            In my opinion, the best approach is to provide both POST and some other method (e.g. the SEARCH or REPORT Webdav methods). Providing POST-queries allows for
            Message 5 of 9 , Nov 22, 2008
            View Source
            • 0 Attachment
              In my opinion, the best approach is to provide both POST and some other
              method (e.g. the SEARCH or REPORT Webdav methods). Providing
              POST-queries allows for easy access, because it is part of HTTP/1.1, but
              if you already use POST for 'create new resource', then you're actually
              overloading it, which is in theory not a good idea. Queries through the
              SEARCH or REPORT method are pretty RESTfully, but it's a disadvantage
              that they are not available in standard API's, which makes it a little
              bit more difficult for clients to access.

              Providing them both allows clients to choose to be very RESTful, or very
              lazy ;)


              Creating a 'query resource' has the disadvantage of having to do two
              requests. And if the query resource is not a part of your logical
              resource domain, then it's a bit ugly to me to create a resource for it.

              This topic has already been adressed on this mailinglist
              (http://tech.groups.yahoo.com/group/rest-discuss/message/10721). Maybe
              you can find some more interesting ways to address this problem in that
              discussion.


              Aristotle Pagaltzis schreef:
              >
              > * Benoît Fleury <benoit.fleury@...
              > <mailto:benoit.fleury%40gmail.com>> [2008-11-21 19:05]:
              > > I was wondering what the preferred approach to make complex
              > > queries over HTTP? I have to provide data in the request body
              > > (It could be a xml description or even an image). The request
              > > is safe.
              >
              > Put in a layer of indirection: let people create a “query asset”
              > by POSTing the body data in a separate request, producing a
              > resource whose URI can be included in the actual query request
              > that they then send as a GET.
              >
              > > The response can't be cached since it depends on the
              > > request body.
              >
              > You are begging the question: you gave no reason for why the
              > response is inherently uncacheable. The specification of GET
              > and POST is not inherent to your problem.
              >
              > > Moreover, the URL does not have to be shared.
              >
              > Better to engineer for serendipity and not decide this up front.
              >
              > Regards,
              > --
              > Aristotle Pagaltzis // <http://plasmasturm.org/ <http://plasmasturm.org/>>
              >
              >


              --
              Barbara Van De Keer

              Ghent University - IBBT
              Faculty of Engineering
              Department of Electronics and Information Systems
              Multimedia Lab
              Gaston Crommenlaan 8 bus 201, B-9050 Ledeberg-Ghent, Belgium

              t: +32 9 33 14959
              f: +32 9 33 14896
              t secr: +32 9 33 14911
              e: barbara.vandekeer@...

              URL: http://multimedialab.elis.ugent.be
            • Aristotle Pagaltzis
              ... I don’t see it that way at all. Resources derive from the solution domain, not part of the problem domain. Creating resources for concepts that the
              Message 6 of 9 , Nov 22, 2008
              View Source
              • 0 Attachment
                * Barbara Van De Keer <Barbara.VanDeKeer@...> [2008-11-22 18:55]:
                > And if the query resource is not a part of your logical
                > resource domain, then it's a bit ugly to me to create a
                > resource for it.

                I don’t see it that way at all. Resources derive from the
                solution domain, not part of the problem domain. Creating
                resources for concepts that the solution requires is how
                modelling works in REST terms; they don’t have to derive
                from any aspect of the problem in order to be justified.

                Consider f.ex. casting transactions or locks as resources.

                Regards,
                --
                Aristotle Pagaltzis // <http://plasmasturm.org/>
              Your message has been successfully submitted and would be delivered to recipients shortly.