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

Re: [rest-discuss] How to do /posts/yyyy[/mm[/dd]] and /posts/id RESTfully?

Expand Messages
  • Joe Gregorio
    ... That is correct, mostly because you are starting from the wrong end of the problem: I have SQL, how do I map that into HTTP . Instead you should be
    Message 1 of 16 , Jun 3, 2007
    • 0 Attachment
      On 5/25/07, Scott Chapman <scott_list@...> wrote:
      >
      > The bigger question that I'm wrestling with is, "How far do you take the
      > mapping of complex queries to the RESTful URL paradigm?" I.e. if you have a
      > query, "SELECT post_id FROM posts WHERE year(post_date) = 2007 and
      > mont(post_date) = 4" how do you map that to RESTful URL's?
      > This gets arbitrarily complex.
      > REST doesn't look like it was made to do a full mapping of URL's to SQL.

      That is correct, mostly because you are starting from the wrong end
      of the problem: "I have SQL, how do I 'map' that into HTTP".

      Instead you should be starting with a RESTful model of your service:

      http://bitworking.org/news/How_to_create_a_REST_Protocol

      And then build out those resources, which may require writing
      some SQL.

      -joe

      --
      Joe Gregorio http://bitworking.org
    • eoinprout
      ... application ... /date ... imply ... isn t there. ... http://en.ericjbowman.com/date;transform=1?iso=2007-05-25 is an RPC way of doing things wouldn t
      Message 2 of 16 , Jun 3, 2007
      • 0 Attachment
        --- In rest-discuss@yahoogroups.com, "Eric J. Bowman" <eric@...> wrote:

        > I'm not sure there's been enough information provided about the
        application
        > in question to make any judgments or apply any preferences. Here's an
        > example, where having a "hackable" URI scheme would be nonsensical:
        >
        > http://en.ericjbowman.com/date;transform=1?iso=2007-05-25
        >
        > I say it does have an orthogonal relationship to REST, in that if my
        /date
        > service had a hierarchical URI allocation scheme it would strongly
        imply
        > a hierarchical organization of the information space which just
        isn't there.
        >
        > -Eric
        >

        http://en.ericjbowman.com/date;transform=1?iso=2007-05-25 is an RPC
        way of doing things

        wouldn't something like
        http://en.ericjbowman.com/date/2007-05-25.iso/LongFormat.html
        be more RESTful.

        http://en.ericjbowman.com/date/2007-05-25.iso/
        would return links to each of the different formats which can be
        returned by your service.
        In this way the service is self describing.
        At the moment someone has to guess what the possible parameters could
        be, The service would become more useful by becoming more hackable.

        What do you think ?

        -Eoin
      • Eric J. Bowman
        ... How so? RPC communication is stateful, in my case, each request from client to server... contain(s) all of the information necessary to understand the
        Message 3 of 16 , Jun 5, 2007
        • 0 Attachment
          >
          >http://en.ericjbowman.com/date;transform=1?iso=2007-05-25 is an RPC
          >way of doing things
          >

          How so? RPC communication is stateful, in my case, "each request from
          client to server... contain(s) all of the information necessary to
          understand the request, and (does not) take advantage of any stored context
          on the server" which is a stateless, RESTful interaction.

          >
          >wouldn't something like
          >http://en.ericjbowman.com/date/2007-05-25.iso/LongFormat.html
          >be more RESTful.
          >

          Not really, URI design is only orthogonal to REST. My way is not the only
          way.

          >
          >http://en.ericjbowman.com/date/2007-05-25.iso/
          >would return links to each of the different formats which can be
          >returned by your service.
          >In this way the service is self describing.
          >At the moment someone has to guess what the possible parameters could
          >be, The service would become more useful by becoming more hackable.
          >

          Well, that's another way to do it. But my way is still self-describing
          because there is a service document which clearly lays out the existence
          and usage of parameters for each language the service is available in, no
          guesswork involved. I'm a bit confused on where self-describing services
          enters into REST, though.

          More usable to whom? If I want to write an XSLT stylesheet which takes the
          primary output and transforms it into RFC 1123 format served as text/plain
          then I just do this after it's written:

          curl -iT "en.2.xsl" http://ericjbowman.com/date/en.2.xsl

          Which does a PUT. I get a 201 Created if it's new, if I've overwritten an
          existing file I get a 204 No Content response. Now, I can GET this:

          http://en.ericjbowman.com/date;transform=2?iso=2007-05-25

          That seems pretty usable to me, as the maintainer of the service, since no
          existing consumers of the service need to be rewritten to accomodate it, no
          new name must be devised which might not apply in the future, and all I have
          to do (if I even want to) is update my service documents to reflect that the
          English version now has this capability (which doesn't make sense for any
          other language).

          Anyway, in terms of REST constraints, it's the messages that are to be
          self-descriptive, not the service itself. Not hierarchical, but still
          hackable:

          http://en.ericjbowman.com/date?iso=2007-05-25

          Also, not RPC because it's perfectly cacheable. Yes, I can set an Etag,
          but we are waiting for Caucho to add MD5 capability to Resin (in the works)
          so we can set Etag=MD5. If this were RPC instead of GET the output would
          not be cacheable at all. Instead, I've optimized GET, which is very RESTful.

          -Eric
        • eoinprout
          ... context ... It looks like RPC to me because it looks like your making a function call rather then requesting the a resource. RPC does not have to be
          Message 4 of 16 , Jun 5, 2007
          • 0 Attachment
            --- In rest-discuss@yahoogroups.com, "Eric J. Bowman" <eric@...> wrote:
            >
            > >
            > >http://en.ericjbowman.com/date;transform=1?iso=2007-05-25 is an RPC
            > >way of doing things
            > >
            >
            > How so? RPC communication is stateful, in my case, "each request from
            > client to server... contain(s) all of the information necessary to
            > understand the request, and (does not) take advantage of any stored
            context
            > on the server" which is a stateless, RESTful interaction.

            It looks like RPC to me because it looks like your making a function
            call rather then requesting the a resource.

            RPC does not have to be stateful.

            > >
            > >wouldn't something like
            > >http://en.ericjbowman.com/date/2007-05-25.iso/LongFormat.html
            > >be more RESTful.
            > >
            >
            > Not really, URI design is only orthogonal to REST. My way is not
            the only
            > way.
            >
            > >
            > >http://en.ericjbowman.com/date/2007-05-25.iso/
            > >would return links to each of the different formats which can be
            > >returned by your service.
            > >In this way the service is self describing.
            > >At the moment someone has to guess what the possible parameters could
            > >be, The service would become more useful by becoming more hackable.
            > >
            >
            > Well, that's another way to do it. But my way is still self-describing
            > because there is a service document which clearly lays out the
            existence
            > and usage of parameters for each language the service is available
            in, no
            > guesswork involved. I'm a bit confused on where self-describing
            services
            > enters into REST, though.

            One way REST is self describing is way a user can traverse links from
            one resource to another related resource rather then knowing the rules
            on how to construct the URLs.
            And you have things like OPTIONS which is supposed to say what
            operations are allowed on a particular resource.

            > More usable to whom? If I want to write an XSLT stylesheet which
            takes the
            > primary output and transforms it into RFC 1123 format served as
            text/plain
            > then I just do this after it's written:
            >
            > curl -iT "en.2.xsl" http://ericjbowman.com/date/en.2.xsl
            >
            > Which does a PUT. I get a 201 Created if it's new, if I've
            overwritten an
            > existing file I get a 204 No Content response. Now, I can GET this:
            >
            > http://en.ericjbowman.com/date;transform=2?iso=2007-05-25
            >
            > That seems pretty usable to me, as the maintainer of the service,
            since no
            > existing consumers of the service need to be rewritten to accomodate
            it, no
            > new name must be devised which might not apply in the future, and
            all I have
            > to do (if I even want to) is update my service documents to reflect
            that the
            > English version now has this capability (which doesn't make sense
            for any
            > other language).
            >
            > Anyway, in terms of REST constraints, it's the messages that are to be
            > self-descriptive, not the service itself. Not hierarchical, but still
            > hackable:
            >
            > http://en.ericjbowman.com/date?iso=2007-05-25
            >
            > Also, not RPC because it's perfectly cacheable. Yes, I can set an
            Etag,
            > but we are waiting for Caucho to add MD5 capability to Resin (in the
            works)
            > so we can set Etag=MD5. If this were RPC instead of GET the output
            would
            > not be cacheable at all. Instead, I've optimized GET, which is very
            RESTful.
            >
            > -Eric
            >

            some systems won't/can't cache GETs which contain parameters.
            But this is more of a flaw with those systems then any flaw in your
            method.

            But as you say they is no one way, This is only my opinion.

            Eoin
          • Keith Gaughan
            ... Treat the URI as opaque. Verbs in a URI might be a bad smell, a very bad smell, but there s nothing RESTful or unRESTful about them. What matters is which
            Message 5 of 16 , Jun 5, 2007
            • 0 Attachment
              eoinprout wrote:

              > --- In rest-discuss@yahoogroups.com, "Eric J. Bowman" <eric@...> wrote:
              >>> http://en.ericjbowman.com/date;transform=1?iso=2007-05-25 is an RPC
              >>> way of doing things
              >>>
              >> How so? RPC communication is stateful, in my case, "each request from
              >> client to server... contain(s) all of the information necessary to
              >> understand the request, and (does not) take advantage of any stored
              > context
              >> on the server" which is a stateless, RESTful interaction.
              >
              > It looks like RPC to me because it looks like your making a function
              > call rather then requesting the a resource.
              >
              > RPC does not have to be stateful.

              Treat the URI as opaque. Verbs in a URI might be a bad smell, a very bad
              smell, but there's nothing RESTful or unRESTful about them. What matters is
              which verb counts: the method verb (in the case of HTTP, GET, PUT, &c.) or the
              one in the identifier. A URI is just an identifier for a resource, and as long
              as clients are able to treat it as such, there's no problem with having
              anything it it.

              That aside, that's one ugly URI!

              >> Well, that's another way to do it. But my way is still self-describing
              >> because there is a service document which clearly lays out the
              >> existence and usage of parameters for each language the service is
              >> available in, no guesswork involved. I'm a bit confused on where
              >> self-describing services enters into REST, though.

              As an addendum to what Eoin wrote, REST is self-describing because responses
              and requests included information in them, in the case of HTTP, Content-Type
              and other headers, which tells the client and server how to parse the message.

              One of the reasons why service documents don't really gel with REST is that
              clients aren't meant to care what the identifiers look like. All they're meant
              to care about is that there are URIs present that can be dereferenced. Where
              this isn't the case, you've got two choices: hardwire the clients or get
              the server to tell the client how to build the URIs by including a template
              _in the response_. This keeps the client and server decoupled from one
              another--a service document is a form of strong coupling--and allows the
              server and client to vary without breaking.

              > One way REST is self describing is way a user can traverse links from
              > one resource to another related resource rather then knowing the rules
              > on how to construct the URLs.
              > And you have things like OPTIONS which is supposed to say what
              > operations are allowed on a particular resource.

              Pity OPTIONS is so underspecified though.

              >> Anyway, in terms of REST constraints, it's the messages that are to be
              >> self-descriptive, not the service itself.

              Once the messages are self-descriptive, so too is the service itself.

              K.

              --
              Blacknight Internet Solutions Ltd. <http://blacknight.ie/>
              Unit 12A Barrowside Business Park, Sleaty Road, Graiguecullen, Carlow, Ireland
              Company No.: 370845
            • Eric J. Bowman
              ... Try this: curl -iX options http://ericjbowman.com/date Tells you which HTTP methods are allowed and tells you the languages the service is available in.
              Message 6 of 16 , Jun 5, 2007
              • 0 Attachment
                >
                >And you have things like OPTIONS which is supposed to say what
                >operations are allowed on a particular resource.
                >

                Try this:

                curl -iX options http://ericjbowman.com/date

                Tells you which HTTP methods are allowed and tells you the languages the
                service is available in. You're seeing an output transformation as an
                option, I see it as merely another representation of my resource, not a
                remote function call -- the client is requesting to GET some data from
                the server -- and this request can easily be fulfilled by an intermediary
                because /date's output is cacheable.

                >
                >some systems won't/can't cache GETs which contain parameters.
                >But this is more of a flaw with those systems then any flaw in your
                >method.
                >

                But, crucially, the cache component of my server connector handles this
                just fine. By using XSLTC's input cache, once any date conversion is
                requested the algorithm doesn't need to run for that date again (provided
                the server stays up). Once an output transformation has been run, the
                results are cached in Resin's HTTP cache. The only system I can control
                would scale very, very well because of this, if need be. Instead of
                running the algorithm every time (which would happen in RPC) I've created
                a cacheable lookup table from the algorithm output.

                -Eric
              • A. Pagaltzis
                ... So what? All requests end up running code on the server. Arguing about whether a URI looks like a function call or not is string theory for the web. ...
                Message 7 of 16 , Jun 6, 2007
                • 0 Attachment
                  * eoinprout <eoin@...> [2007-06-05 14:15]:
                  > It looks like RPC to me because it looks like your making a
                  > function call rather then requesting the a resource.

                  So what? All requests end up running code on the server. Arguing
                  about whether a URI looks like a function call or not is string
                  theory for the web.

                  > RPC does not have to be stateful.

                  That’s not even wrong. It’s like saying RESTful systems do not
                  have to have more than a single resource. In neither case can
                  you talk about an architectural style.

                  Regards,
                  --
                  Aristotle Pagaltzis // <http://plasmasturm.org/>
                • Eric J. Bowman
                  ... It only smells bad if you insist transform is a verb. I see it as synonymous with channel -- which is a noun. It makes sense to me as the consumer of
                  Message 8 of 16 , Jun 7, 2007
                  • 0 Attachment
                    >
                    >Treat the URI as opaque. Verbs in a URI might be a bad smell, a very bad
                    >smell, but there's nothing RESTful or unRESTful about them. What matters is
                    >which verb counts: the method verb (in the case of HTTP, GET, PUT, &c.) or the
                    >one in the identifier. A URI is just an identifier for a resource, and as long
                    >as clients are able to treat it as such, there's no problem with having
                    >anything it it.
                    >

                    It only smells bad if you insist "transform" is a verb. I see it as
                    synonymous with "channel" -- which is a noun. It makes sense to me as the
                    consumer of a service which has a variety of output transformations for any
                    given resource. Since the query doesn't change, only the representation,
                    and since it's optional I see this as a valid use for URI parameters.

                    Ugly or not. ;-)

                    -Eric
                  Your message has been successfully submitted and would be delivered to recipients shortly.