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

Re: [rest-discuss] 30x Status codes

Expand Messages
  • Julian Reschke
    ... It s a temporary redirect, so 307 would be correct. However, where s the point in forcing the redirect at all? Best regards, Julian
    Message 1 of 15 , Oct 2, 2007
    • 0 Attachment
      Brandon Carlson wrote:
      >
      >
      > All,
      >
      > I seem to have lost rational thought at moment and would like some
      > advice.
      >
      > Let's assume a RESTful weather service with the URIs looking
      > something like this:
      >
      > # Daily forecast
      > forecast/2007/ 10/02
      >
      > # Today's forecast
      > forecast/today
      >
      > I would expect the URI for today's forecast to redirect to the
      > forecast for today's date. My question is which redirect to use. My
      > first thought is that I would use a 301, but then, the more I
      > thought about it I think a 302/307 is the correct choice.
      >
      > What does the group think?
      >
      > Thanks!
      > Brandon

      It's a temporary redirect, so 307 would be correct.

      However, where's the point in forcing the redirect at all?

      Best regards, Julian
    • Peter Lacey
      ... From the POV of a GET a 303 and 307 are very similar. However, a 307 is a temporary redirect which to me implies I ve moved the resource over there for
      Message 2 of 15 , Oct 2, 2007
      • 0 Attachment
        Julian Reschke wrote:
        > Brandon Carlson wrote:
        > >
        > > Let's assume a RESTful weather service with the URIs looking
        > > something like this:
        > >
        > > # Daily forecast
        > > forecast/2007/ 10/02
        > >
        > > # Today's forecast
        > > forecast/today
        > >
        > > I would expect the URI for today's forecast to redirect to the
        > > forecast for today's date. My question is which redirect to use. My
        > > first thought is that I would use a 301, but then, the more I
        > > thought about it I think a 302/307 is the correct choice.
        > >
        > > What does the group think?
        >
        > It's a temporary redirect, so 307 would be correct.
        >
        > However, where's the point in forcing the redirect at all?
        >
        From the POV of a GET a 303 and 307 are very similar. However, a 307
        is a "temporary redirect" which to me implies "I've moved the resource
        over there for a little while, but next time you need it it might be
        back here." While a 303, "see other," says to me "I understand what
        you're looking for, and I'm sending you over there to get it."

        Why redirect? Quoting the RWS book " The 303 status code is a good way
        to canonicalize your resources. You can make them available through many
        URIs, but only have one "real" URI per representation. All the other
        URIs use a 303 to point to the canonical URI for that representation.
        For instance, a 303 might redirect a request for
        http://www.example.com/software/current.tar.gz to the URI
        http://www.example.com/software/1.0.2.tar.gz."

        From the same source, 302 is to be avoided due to ambiguity issues.

        -- Pete
      • Stefan Tilkov
        ... Which of course means an extra client/server roundtrip, which may or may not be acceptable. Stefan -- Stefan Tilkov, http://www.innoq.com/blog/st/
        Message 3 of 15 , Oct 2, 2007
        • 0 Attachment
          On Oct 2, 2007, at 4:16 PM, Peter Lacey wrote:

          > The 303 status code is a good way
          > to canonicalize your resources. You can make them available through
          > many
          > URIs, but only have one "real" URI per representation.

          Which of course means an extra client/server roundtrip, which may or
          may not be acceptable.

          Stefan
          --
          Stefan Tilkov, http://www.innoq.com/blog/st/
        • Peter Lacey
          ... It does, but the proper use of HTTP frequently requires multiple trips. Certainly redirects are common enough. And, if you want to treat them differently,
          Message 4 of 15 , Oct 2, 2007
          • 0 Attachment
            Stefan Tilkov wrote:
            > On Oct 2, 2007, at 4:16 PM, Peter Lacey wrote:
            >
            >> The 303 status code is a good way
            >> to canonicalize your resources. You can make them available through many
            >> URIs, but only have one "real" URI per representation.
            >
            > Which of course means an extra client/server roundtrip, which may or
            > may not be acceptable.
            >
            > Stefan
            > --
            > Stefan Tilkov, http://www.innoq.com/blog/st/
            It does, but the proper use of HTTP frequently requires multiple trips.
            Certainly redirects are common enough. And, if you want to treat them
            differently, there's also a few 2Xx responses after a POST/PUT that
            might encourage a client to go back to the server. HEAD and OPTION
            usually imply a future trip to the server, too. Also, in the case of a
            GET, the first trip is pretty lightweight; headers only. Similarly,
            form-based links that allow compliance with HATEOAS (God, I hate that
            term) requires an extra trip. Want to look up a person? Can you
            construct a link, e.g., http://example.com/users?first_name="Stefan" ?
            Not without, getting a form first. Finally, 303s mean a cache can store
            less information, and perform the redirection on the server's behalf.
            Ultimately, though, circumstances will help you decide whether the
            expense of a 303 outweighs simply returning the resource.

            -- Pete
          • Brandon Carlson
            agreed. Because the 303 is already pretty lightweight I think it would be ok. I suppose however that it entirely depends on the client s caching strategy. When
            Message 5 of 15 , Oct 2, 2007
            • 0 Attachment
              agreed. Because the 303 is already pretty lightweight I think it would
              be ok. I suppose however that it entirely depends on the client's
              caching strategy. When recieving a 303, should the client discontinue
              using the source URI for subsequent calls, if so, for how long? When
              should it return to the source?

              In my case, the dates really are a snapshot in time and will never
              change once created so the target of the redirect can be cached
              indefinitely.

              Thanks!
              brandon

              On 10/2/07, Stefan Tilkov <stefan.tilkov@...> wrote:
              > On Oct 2, 2007, at 4:16 PM, Peter Lacey wrote:
              >
              > > The 303 status code is a good way
              > > to canonicalize your resources. You can make them available through
              > > many
              > > URIs, but only have one "real" URI per representation.
              >
              > Which of course means an extra client/server roundtrip, which may or
              > may not be acceptable.
              >
              > Stefan
              > --
              > Stefan Tilkov, http://www.innoq.com/blog/st/
            • Nick Gall
              ... Wouldn t using the Content-Location HTTP header field also be a good way to canonicalize your resources ? The Content-Location entity-header field MAY be
              Message 6 of 15 , Oct 2, 2007
              • 0 Attachment
                On 10/2/07, Peter Lacey <placey@...> wrote:
                >  Why redirect?  Quoting the RWS book " The 303 status code is a good way
                >  to canonicalize your resources. You can make them available through many
                >  URIs, but only have one "real" URI per representation. All the other
                >  URIs use a 303 to point to the canonical URI for that representation.
                >  For instance, a 303 might redirect a request for
                >  http://www.example.com/software/current.tar.gz to the URI
                >  http://www.example.com/software/1.0.2.tar.gz
                ."

                Wouldn't using the Content-Location HTTP header field also be a "good way to canonicalize your resources"?

                The Content-Location entity-header field MAY be used to supply the resource location for the entity enclosed in the message when that entity is accessible from a location separate from the requested resource's URI. A server SHOULD provide a Content-Location for the variant corresponding to the response entity; especially in the case where a resource has multiple entities associated with it, and those entities actually have separate locations by which they might be individually accessed, the server SHOULD provide a Content-Location for the particular variant which is returned.

                It has the advantage of NOT requiring a round trip.

                -- Nick
              • Mark Baker
                ... In theory, yes. In practice in the wild, not so much. See this thread; http://lists.w3.org/Archives/Public/ietf-http-wg/2007JulSep/0269.html Mark. --
                Message 7 of 15 , Oct 2, 2007
                • 0 Attachment
                  On 10/2/07, Nick Gall <nick.gall@...> wrote:
                  >
                  > On 10/2/07, Peter Lacey <placey@...> wrote:
                  > > Why redirect? Quoting the RWS book " The 303 status code is a good way
                  > > to canonicalize your resources. You can make them available through many
                  > > URIs, but only have one "real" URI per representation. All the other
                  > > URIs use a 303 to point to the canonical URI for that representation.
                  > > For instance, a 303 might redirect a request for
                  > > http://www.example.com/software/current.tar.gz to the URI
                  > > http://www.example.com/software/1.0.2.tar.gz ."
                  >
                  > Wouldn't using the Content-Location HTTP header field also be a "good way to canonicalize your resources"?
                  >
                  >
                  > The Content-Location entity-header field MAY be used to supply the resource location for the entity enclosed in the message when that entity is accessible from a location separate from the requested resource's URI. A server SHOULD provide a Content-Location for the variant corresponding to the response entity; especially in the case where a resource has multiple entities associated with it, and those entities actually have separate locations by which they might be individually accessed, the server SHOULD provide a Content-Location for the particular variant which is returned.
                  >
                  > It has the advantage of NOT requiring a round trip.

                  In theory, yes. In practice in the wild, not so much. See this thread;

                  http://lists.w3.org/Archives/Public/ietf-http-wg/2007JulSep/0269.html

                  Mark.
                  --
                  Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
                  Coactus; Web-inspired integration strategies http://www.coactus.com
                • Nick Gall
                  ... Agreed. But I was thinking about Web API (programmatic) use of HTTP as opposed to typical browser behavior. As long as one documented one s interface and
                  Message 8 of 15 , Oct 2, 2007
                  • 0 Attachment
                    On 10/2/07, Mark Baker <distobj@...> wrote:
                    > On 10/2/07, Nick Gall <nick.gall@...> wrote:
                    > > Wouldn't using the Content-Location HTTP header field also be a "good way to canonicalize your resources"?
                    >
                    > In theory, yes. In practice in the wild, not so much.

                    Agreed. But I was thinking about "Web API" (programmatic) use of HTTP
                    as opposed to typical browser behavior. As long as one documented
                    one's interface and clients used HTTP libraries with full access to
                    headers, then using Content-Location should be straightforward. Unless
                    intermediaries (eg caches) typically strip such headers in flight. Do
                    they?

                    -- Nick

                    --
                    Nick Gall
                    Phone: +1.781.608.5871
                    AOL IM: Nicholas Gall
                    Yahoo IM: nick_gall_1117
                    MSN IM: (same as email)
                    Google Talk: (same as email)
                    Email: nick.gall AT-SIGN gmail DOT com
                    Weblog: http://ironick.typepad.com/ironick/
                    Furl: http://www.furl.net/members/ngall
                  • Mark Baker
                    ... I believe that s what Roy said, yes. Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Coactus; Web-inspired integration
                    Message 9 of 15 , Oct 2, 2007
                    • 0 Attachment
                      On 10/2/07, Nick Gall <nick.gall@...> wrote:
                      > On 10/2/07, Mark Baker <distobj@...> wrote:
                      > > On 10/2/07, Nick Gall <nick.gall@...> wrote:
                      > > > Wouldn't using the Content-Location HTTP header field also be a "good way to canonicalize your resources"?
                      > >
                      > > In theory, yes. In practice in the wild, not so much.
                      >
                      > Agreed. But I was thinking about "Web API" (programmatic) use of HTTP
                      > as opposed to typical browser behavior. As long as one documented
                      > one's interface and clients used HTTP libraries with full access to
                      > headers, then using Content-Location should be straightforward. Unless
                      > intermediaries (eg caches) typically strip such headers in flight. Do
                      > they?

                      I believe that's what Roy said, yes.

                      Mark.
                      --
                      Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
                      Coactus; Web-inspired integration strategies http://www.coactus.com
                    • Roy T. Fielding
                      ... I meant to say that origin servers sometimes don t know what their own real URI should be due to the presence of intermediaries that rewrite incoming
                      Message 10 of 15 , Oct 2, 2007
                      • 0 Attachment
                        On Oct 2, 2007, at 3:28 PM, Mark Baker wrote:
                        > On 10/2/07, Nick Gall <nick.gall@...> wrote:
                        > > On 10/2/07, Mark Baker <distobj@...> wrote:
                        > > > On 10/2/07, Nick Gall <nick.gall@...> wrote:
                        > > > > Wouldn't using the Content-Location HTTP header field also be
                        > a "good way to canonicalize your resources"?
                        > > >
                        > > > In theory, yes. In practice in the wild, not so much.
                        > >
                        > > Agreed. But I was thinking about "Web API" (programmatic) use of
                        > HTTP
                        > > as opposed to typical browser behavior. As long as one documented
                        > > one's interface and clients used HTTP libraries with full access to
                        > > headers, then using Content-Location should be straightforward.
                        > Unless
                        > > intermediaries (eg caches) typically strip such headers in
                        > flight. Do
                        > > they?
                        >
                        > I believe that's what Roy said, yes.

                        I meant to say that origin servers sometimes don't know
                        what their own real URI should be due to the presence of
                        intermediaries that rewrite incoming requests. And, because
                        those same intermediaries aren't smart enough to rewrite
                        responses that contain C-Location values (or simply don't know
                        if the origin server already did that for them), the resulting
                        field value is often wrong.

                        That could be solvable using relative values for the
                        location and a better description in the spec. I am not
                        convinced that the 209 code is needed. OTOH, I also heard
                        second-hand complaints from browser implementers that IIS is
                        sending bogus location values by default.

                        ....Roy
                      • A. Pagaltzis
                        ... Yeah, me too; which is why a while back I proposed saying “hypermedia-driven application state” instead, whose initialism is HDAS, and whose long form
                        Message 11 of 15 , Oct 2, 2007
                        • 0 Attachment
                          * Peter Lacey <placey@...> [2007-10-02 19:35]:
                          > compliance with HATEOAS (God, I hate that term)

                          Yeah, me too; which is why a while back I proposed saying
                          “hypermedia-driven application state” instead, whose initialism
                          is HDAS, and whose long form rolls of the tongue with nicely
                          rhythmically if you cut “application” to “app.” People weren’t
                          very enthusiastic about the idea, though.

                          So instead I’ve taken to saying “the hypermedia constraint” or
                          sometimes just “hypermedia” over either “HATEOAS” or using the
                          full phrase. Eg. in this case it’d be:

                          Similarly, form-based links that allow compliance with the
                          hypermedia constraint require an extra trip.

                          Try that, I find it helps.

                          Regards,
                          --
                          Aristotle Pagaltzis // <http://plasmasturm.org/>
                        • Roy T. Fielding
                          ... The word hypertext should have been enough, but it actually means very different things to different people (especially those within the hypertext
                          Message 12 of 15 , Oct 2, 2007
                          • 0 Attachment
                            On Oct 2, 2007, at 6:02 PM, A. Pagaltzis wrote:
                            > * Peter Lacey <placey@...> [2007-10-02 19:35]:
                            > > compliance with HATEOAS (God, I hate that term)
                            >
                            > Yeah, me too; which is why a while back I proposed saying
                            > “hypermedia-driven application state” instead, whose initialism
                            > is HDAS, and whose long form rolls of the tongue with nicely
                            > rhythmically if you cut “application” to “app.” People weren’t
                            > very enthusiastic about the idea, though.
                            >
                            > So instead I’ve taken to saying “the hypermedia constraint” or
                            > sometimes just “hypermedia” over either “HATEOAS” or using the
                            > full phrase. Eg. in this case it’d be:
                            >
                            > Similarly, form-based links that allow compliance with the
                            > hypermedia constraint require an extra trip.

                            The word "hypertext" should have been enough, but it actually
                            means very different things to different people (especially
                            those within the hypertext research community). I can't just
                            shorten it to "hyperstate" either, since that would imply
                            "much more state" (not what we want).

                            It has some aspects in common with "data reactive" engines, as in

                            http://www.cs.uoregon.edu/research/paraducks/papers/tr9605.d/

                            though I wasn't aware of that paper until 10 minutes ago.
                            Much of the software architecture research on constraints was
                            influenced by the GUI work on constraint-based layout toolkits.

                            I would suggest calling it the "hypertext constraint" when in
                            normal discussion, or the "reactive constraint" when within
                            slapping distance of a literary hypertext fan.

                            ....Roy
                          • Nick Gall
                            ... I agree that hypertext constraint should be enough because properly understood, the hyper in hypertext specifically refers to embedding control
                            Message 13 of 15 , Oct 2, 2007
                            • 0 Attachment
                              On 10/2/07, Roy T. Fielding <fielding@...> wrote:
                              > The word "hypertext" should have been enough, but it actually
                              > means very different things to different people (especially
                              > those within the hypertext research community).  I can't just
                              > shorten it to "hyperstate" either, since that would imply
                              > "much more state" (not what we want).
                              >
                              > It has some aspects in common with "data reactive" engines, as in
                              >
                              >   http://www.cs.uoregon.edu/research/paraducks/papers/tr9605.d/
                              >
                              > though I wasn't aware of that paper until 10 minutes ago.
                              > Much of the software architecture research on constraints was
                              > influenced by the GUI work on constraint-based layout toolkits.
                              >
                              > I would suggest calling it the "hypertext constraint" when in
                              > normal discussion, or the "reactive constraint" when within
                              > slapping distance of a literary hypertext fan.

                              I agree that "hypertext constraint" should be enough because properly understood, the "hyper" in hypertext specifically refers to embedding control structure in the form of links in "text". However, such proper understanding is the exception not the rule.

                              One could call it the "Hypertext as Closure" (HaC) constraint when within slapping distance of Lisp/Scheme/Functional Programming Fans. <grin> It has the advantage of the cool acronym "HaC", which connotes hack (in the positive sense of the term -- a clever solution to a CS problem).

                              -- Nick
                            • Mike Dierken
                              How about HEAPPS - Hypertext as the Engine of APPlication State.
                              Message 14 of 15 , Oct 2, 2007
                              • 0 Attachment
                                How about HEAPPS - Hypertext as the Engine of APPlication State.


                                On 10/2/07, Nick Gall <nick.gall@... > wrote:
                                On 10/2/07, Roy T. Fielding <fielding@...> wrote:
                                > The word "hypertext" should have been enough, but it actually
                                > means very different things to different people (especially
                                > those within the hypertext research community).  I can't just
                                > shorten it to "hyperstate" either, since that would imply
                                > "much more state" (not what we want).
                                >
                                > It has some aspects in common with "data reactive" engines, as in
                                >
                                >   http://www.cs.uoregon.edu/research/paraducks/papers/tr9605.d/
                                >
                                > though I wasn't aware of that paper until 10 minutes ago.
                                > Much of the software architecture research on constraints was
                                > influenced by the GUI work on constraint-based layout toolkits.
                                >
                                > I would suggest calling it the "hypertext constraint" when in
                                > normal discussion, or the "reactive constraint" when within
                                > slapping distance of a literary hypertext fan.

                                I agree that "hypertext constraint" should be enough because properly understood, the "hyper" in hypertext specifically refers to embedding control structure in the form of links in "text". However, such proper understanding is the exception not the rule.

                                One could call it the "Hypertext as Closure" (HaC) constraint when within slapping distance of Lisp/Scheme/Functional Programming Fans. <grin> It has the advantage of the cool acronym "HaC", which connotes hack (in the positive sense of the term -- a clever solution to a CS problem).

                                -- Nick

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