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

Re: [rest-discuss] 30x Status codes

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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.