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

Re: [rest-discuss] HTTP request and "type safety"

Expand Messages
  • Roy T. Fielding
    ... Ah, yes, a similar thing happens all the time when flaying frisbee in the park with my dog. When I throw the frisbee and the dog tries to catch it in his
    Message 1 of 18 , Mar 9, 2010
    View Source
    • 0 Attachment
      On Mar 9, 2010, at 9:48 AM, <jumeier@...> <jumeier@...> wrote:

      > I have a customer who raised a concern about REST "type safety". What he means may be best explained by a simple example.
      >
      > Assume we have a resource that represents a folder, and by issueing a POST request, I can attach a file. What, however, if that post request wrongly goes to, let's say, another document resource instead of our folder, and the document resource also accepts POST (for some reason)?
      >
      > In a RPC world, the document type would not understand an "addDocument()" call, and consequently return an exception. But what about REST? Of course, the POST's attributes most likely wouldn't be understood and something like 400 Bad Request returned. But what if they were understood?

      Ah, yes, a similar thing happens all the time when
      flaying frisbee in the park with my dog. When I throw
      the frisbee and the dog tries to catch it in his teeth,
      everyone seems to be happy. However, when the dog tries
      to throw the frisbee and I try to catch it in my teeth,
      it just doesn't seem to work well for either of us.

      > So, are there means or patterns, to achieve (some sort) of type safety?

      Yes. A RESTful interface is one where the server provides the links
      or forms that tells the client what operations to perform where.
      If you are telling the client to do the wrong thing, then the
      pattern would be to tell the client to do the right thing instead.
      Generally speaking, it works out better that way.

      ....Roy
    • William Martinez Pomares
      OK. Let me add to that. 1. Let s no call it RPC, it is just plain method invocation, for the matter at hand it is the same thing. In this case, the idea of
      Message 2 of 18 , Mar 10, 2010
      View Source
      • 0 Attachment
        OK. Let me add to that.

        1. Let's no call it RPC, it is just plain method invocation, for the matter at hand it is the same thing. In this case, the idea of type safety works just the same. For objects, you have type checking when you send a message to the wrong object. You also have type checking when you send parameters. But there could be the case where two different object (different classes) have a method named the same, and receiving the same number of parameters, and the same parameter types too! In this case you face the exact problem. SO the problem goes down to a clumsy API definition and a lost programmer that makes the wrong calls.

        2. Now, in REST you are supposed to create your client to discover state transitions. You start with one URL, and from there, each resource representation will tell you, through hypermedia, where can you go next and what info you need to provide, also which operations to execute to perform that transition. If that is in place, and you are writing the client to go post to a document URL manually (and thus, causing the error you mention) then it is your fault, not REST, since you are not following the rules.
        On the other hand, if your resource representation provides the wrong URL, making your correctly programmed client to commit a mistake, then the one to blame is not REST, but the programmer that created the resource representation.

        If you think about it, the same error you get using any other thing than REST.
        Also, as with any other interaction technique, the one that receives data to be processed, should check the data is correct. If you send your social security number to a method expecting the time in milliseconds, you need to find a way in that method to validate the amount of milliseconds is a valid date. If it happens to be, then you are in trouble, being REST or not.

        William Martinez.

        --- In rest-discuss@yahoogroups.com, "Roy T. Fielding" <fielding@...> wrote:
        >
        > On Mar 9, 2010, at 9:48 AM, <jumeier@...> <jumeier@...> wrote:
        >
        > > I have a customer who raised a concern about REST "type safety". What he means may be best explained by a simple example.
        > >
        > > Assume we have a resource that represents a folder, and by issueing a POST request, I can attach a file. What, however, if that post request wrongly goes to, let's say, another document resource instead of our folder, and the document resource also accepts POST (for some reason)?
        > >
        > > In a RPC world, the document type would not understand an "addDocument()" call, and consequently return an exception. But what about REST? Of course, the POST's attributes most likely wouldn't be understood and something like 400 Bad Request returned. But what if they were understood?
        >
        > Ah, yes, a similar thing happens all the time when
        > flaying frisbee in the park with my dog. When I throw
        > the frisbee and the dog tries to catch it in his teeth,
        > everyone seems to be happy. However, when the dog tries
        > to throw the frisbee and I try to catch it in my teeth,
        > it just doesn't seem to work well for either of us.
        >
        > > So, are there means or patterns, to achieve (some sort) of type safety?
        >
        > Yes. A RESTful interface is one where the server provides the links
        > or forms that tells the client what operations to perform where.
        > If you are telling the client to do the wrong thing, then the
        > pattern would be to tell the client to do the right thing instead.
        > Generally speaking, it works out better that way.
        >
        > ....Roy
        >
      • António Mota
        2010/3/10 Roy T. Fielding ... All that is very well in a perfect world, but what if the client is of a malicious nature, and it s nature
        Message 3 of 18 , Mar 10, 2010
        View Source
        • 0 Attachment
          2010/3/10 Roy T. Fielding <fielding@...>
           

          Yes. A RESTful interface is one where the server provides the links
          or forms that tells the client what operations to perform where.
          If you are telling the client to do the wrong thing, then the
          pattern would be to tell the client to do the right thing instead.


          All that is very well in a perfect world, but what if the client is of a malicious nature, and it's nature lead him to overcome what the server provides, by issuing a request that he may learned from introspection of another application state?

           
        • Subbu Allamaraju
          ... It does not take out the responsibility of input validation and other security measures. The hypertext can very well include markers that the server can
          Message 4 of 18 , Mar 10, 2010
          View Source
          • 0 Attachment
            On Mar 10, 2010, at 6:50 AM, António Mota wrote:

            > All that is very well in a perfect world, but what if the client is of a malicious nature, and it's nature lead him toovercome what the server provides, by issuing a request that he may learned from introspection of another application state?

            It does not take out the responsibility of input validation and other security measures. The hypertext can very well include markers that the server can verify to deal with malicious clients.

            (The recipes on one-time URIs in the RESTful Web Services Cookbook provide examples.)

            Subbu
          • Guilherme Silveira
            ... And your dog ends up complaining that you don t know how to do his job, is it?
            Message 5 of 18 , Mar 10, 2010
            View Source
            • 0 Attachment
              Ah, yes, a similar thing happens all the time when
              flaying frisbee in the park with my dog. When I throw
              the frisbee and the dog tries to catch it in his teeth,
              everyone seems to be happy. However, when the dog tries
              to throw the frisbee and I try to catch it in my teeth,
              it just doesn't seem to work well for either of us.

              And your dog ends up complaining that you don't know how to do his job, is it?
               


              > So, are there means or patterns, to achieve (some sort) of type safety?

              Yes. A RESTful interface is one where the server provides the links
              or forms that tells the client what operations to perform where.
              If you are telling the client to do the wrong thing, then the
              pattern would be to tell the client to do the right thing instead.
              Generally speaking, it works out better that way.

              ....Roy


            • Roy T. Fielding
              ... How is that relevant to type safety? The only difference between a strongly typed distributed system and a weakly typed distributed system is that the
              Message 6 of 18 , Mar 10, 2010
              View Source
              • 0 Attachment
                On Mar 10, 2010, at 6:50 AM, António Mota wrote:
                > 2010/3/10 Roy T. Fielding <fielding@...>
                >> Yes. A RESTful interface is one where the server provides the links
                >> or forms that tells the client what operations to perform where.
                >> If you are telling the client to do the wrong thing, then the
                >> pattern would be to tell the client to do the right thing instead.
                >>
                >
                > All that is very well in a perfect world, but what if the client is of a malicious nature, and it's nature lead him to overcome what the server provides, by issuing a request that he may learned from introspection of another application state?

                How is that relevant to type safety? The only difference between
                a strongly typed distributed system and a weakly typed distributed
                system is that the former gives the attacker one more thing to lie
                about.

                The input has to be validated no matter how or where it has been defined.

                ....Roy
              • Kevin Duffey
                I am confused a bit about this. I was just thinking this today. If I provide a single URI point of entry, and an OPTION or GET request is sent, it returns some
                Message 7 of 18 , Mar 12, 2010
                View Source
                • 0 Attachment

                  I am confused a bit about this. I was just thinking this today. If I provide a single URI point of entry, and an OPTION or GET request is sent, it returns some relevant links that can be called based on the state of the resource. Now, to get those links, I have to first access the point of entry URI. What happens if say a bot program (or even a client developer) decides to cache/save these URIs that return. Then at some point later, call those URIs directly instead of the point of entry URI first to get those URIs back. They could even navigate some links for a while, then save the various URIs deeper down. Later, call those directly.

                  My confusion of this is because the server side is stateless. It retains no state. So how can I validate a URI that a client/bot saved from some previous use, to make sure it's valid at the time of call? I have no state on the server side that says "this URI is being called BEFORE the URI that returns this URI was called.. it's a bad call". So I am unsure as to how to validate every single URI call to make sure it was called at a time when it should be called, and not just randomly out of order. I suppse we can use some sort of timestamp on every single URI that goes back, not sure entirely how that would work at this point, but I suppose the server would check this value when it came back in to the current server time stamp and make sure it's within so many minutes of when it was issued. But a smart client developer/bot could possibly figure that out, and update this value before making the request, and since the server keeps no state, if the modified timestamp is within the right time of the server, it would void that route of validating a URI.




                  > All that is very well in a perfect world, but what if the client is of a malicious nature, and it's nature lead him to overcome what the server provides, by issuing a request that he may learned from introspection of another application state?

                  How is that relevant to type safety? The only difference between
                  a strongly typed distributed system and a weakly typed distributed
                  system is that the former gives the attacker one more thing to lie
                  about.

                  The input has to be validated no matter how or where it has been defined.


                • Peter Williams
                  ... A URI that is saved -- iow, bookmarked -- counts as an entry point URI. This sort of bookmarking is required to implement many kinds of systems composed
                  Message 8 of 18 , Mar 13, 2010
                  View Source
                  • 0 Attachment
                    On Fri, Mar 12, 2010 at 9:57 PM, Kevin Duffey <andjarnic@...> wrote:

                    > I am confused a bit about this. I was just thinking this today. If I
                    > provide a single URI point of entry, and an OPTION or GET request is
                    > sent, it returns some relevant links that can be called based on the
                    > state of the resource. Now, to get those links, I have to first
                    > access the point of entry URI. What happens if say a bot program (or
                    > even a client developer) decides to cache/save these URIs that
                    > return. Then at some point later, call those URIs directly instead
                    > of the point of entry URI first to get those URIs back. They could
                    > even navigate some links for a while, then save the various URIs
                    > deeper down. Later, call those directly.

                    A URI that is saved -- iow, bookmarked -- counts as an entry point
                    URI. This sort of bookmarking is required to implement many kinds of
                    systems composed of multiple components that expose REST style
                    interfaces.

                    Of course, there is no guarantee that URIs saved by a client will
                    remain valid over time. Clients that save URIs must accept that the
                    resources those URIs name may disappear as any point in the future.
                    Well behaved servers do not disable URIs capriciously (see Cool URIs),
                    but resources do have life-cycles that are governed by their domain.


                    > My confusion of this is because the server side is stateless. It
                    > retains no state. So how can I validate a URI that a client/bot
                    > saved from some previous use, to make sure it's valid at the time of
                    > call? I have no state on the server side that says "this URI is
                    > being called BEFORE the URI that returns this URI was called.. it's
                    > a bad call". So I am unsure as to how to validate every single URI
                    > call to make sure it was called at a time when it should be called,
                    > and not just randomly out of order. I suppse we can use some sort of
                    > timestamp on every single URI that goes back, not sure entirely how
                    > that would work at this point, but I suppose the server would check
                    > this value when it came back in to the current server time stamp and
                    > make sure it's within so many minutes of when it was issued. But a
                    > smart client developer/bot could possibly figure that out, and
                    > update this value before making the request, and since the server
                    > keeps no state, if the modified timestamp is within the right time
                    > of the server, it would void that route of validating a URI.

                    Why do you care if the resources are accessed "out of order"?

                    If there are domain reasons for a resource to be available for a
                    limited time, the application logic should destroy/deactivate the
                    resource once it is no longer valid. In that case, this hypothetical
                    client with get a 410 or 404 when it attempts to make requests of the
                    now nonexistent resource.

                    If there is no domain reason for the resource to expire why is it a
                    problem for a client to save a URI and the access it later?

                    Peter
                    http://barelyenough.org
                  • Kevin Duffey
                    Hi Peter, As for why I care.. I don t.. I thought it would not be HATEOAS if a URI could be accessed directly and not discovered ? From all the posts, it
                    Message 9 of 18 , Mar 14, 2010
                    View Source
                    • 0 Attachment
                      Hi Peter,

                      As for why I care.. I don't.. I thought it would not be HATEOAS if a URI could be accessed directly and not "discovered"? From all the posts, it seemed to me that if you accessed any URI directly, and not via an initial URI entry point that then gave you URIs you could use based on the resource state, I figured that was not the HATEOAS/REST way. I couldn't figure out how you could actually validate that a URI was called based on a URI you passed back previously, given the no state restraint in terms of resources on the server side.

                      I suppose tho, that a client should not save URIs for future direct access, as data may change, even resources could change, hence the ability to evolve the server side without breaking the client.


                      --- On Sat, 3/13/10, Peter Williams <pezra@...> wrote:

                      From: Peter Williams <pezra@...>
                      Subject: Re: [rest-discuss] HTTP request and "type safety"
                      To: "Kevin Duffey" <andjarnic@...>, "Rest List" <rest-discuss@yahoogroups.com>
                      Date: Saturday, March 13, 2010, 8:37 AM

                      On Fri, Mar 12, 2010 at 9:57 PM, Kevin Duffey <andjarnic@...> wrote:

                      > I am confused a bit about this. I was just thinking this today. If I
                      > provide a single URI point of entry, and an OPTION or GET request is
                      > sent, it returns some relevant links that can be called based on the
                      > state of the resource. Now, to get those links, I have to first
                      > access the point of entry URI. What happens if say a bot program (or
                      > even a client developer) decides to cache/save these URIs that
                      > return. Then at some point later, call those URIs directly instead
                      > of the point of entry URI first to get those URIs back. They could
                      > even navigate some links for a while, then save the various URIs
                      > deeper down. Later, call those directly.

                      A URI that is saved -- iow, bookmarked -- counts as an entry point
                      URI.  This sort of bookmarking is required to implement many kinds of
                      systems composed of multiple components that expose REST style
                      interfaces.

                      Of course, there is no guarantee that URIs saved by a client will
                      remain valid over time.  Clients that save URIs must accept that the
                      resources those URIs name may disappear as any point in the future.
                      Well behaved servers do not disable URIs capriciously (see Cool URIs),
                      but resources do have life-cycles that are governed by their domain.


                      > My confusion of this is because the server side is stateless. It
                      > retains no state. So how can I validate a URI that a client/bot
                      > saved from some previous use, to make sure it's valid at the time of
                      > call? I have no state on the server side that says "this URI is
                      > being called BEFORE the URI that returns this URI was called.. it's
                      > a bad call". So I am unsure as to how to validate every single URI
                      > call to make sure it was called at a time when it should be called,
                      > and not just randomly out of order. I suppse we can use some sort of
                      > timestamp on every single URI that goes back, not sure entirely how
                      > that would work at this point, but I suppose the server would check
                      > this value when it came back in to the current server time stamp and
                      > make sure it's within so many minutes of when it was issued. But a
                      > smart client developer/bot could possibly figure that out, and
                      > update this value before making the request, and since the server
                      > keeps no state, if the modified timestamp is within the right time
                      > of the server, it would void that route of validating a URI.

                      Why do you care if the resources are accessed "out of order"?

                      If there are domain reasons for a resource to be available for a
                      limited time, the application logic should destroy/deactivate the
                      resource once it is no longer valid.  In that case, this hypothetical
                      client with get a 410 or 404 when it attempts to make requests of the
                      now nonexistent resource.

                      If there is no domain reason for the resource to expire why is it a
                      problem for a client to save a URI and the access it later?

                      Peter
                      http://barelyenough.org

                    • Subbu Allamaraju
                      ... Please see http://my.safaribooksonline.com/9780596809140/recipe-how-to-generate-one-time-uris (sorry - requires a purchase to read) Subbu
                      Message 10 of 18 , Mar 14, 2010
                      View Source
                      • 0 Attachment
                        > I couldn't figure out how you could actually validate that a URI was called based on a URI you passed back previously, given the no state restraint in terms of resources on the server side.

                        Please see

                        http://my.safaribooksonline.com/9780596809140/recipe-how-to-generate-one-time-uris

                        (sorry - requires a purchase to read)

                        Subbu

                        >
                        >
                        > --- On Sat, 3/13/10, Peter Williams <pezra@...> wrote:
                        >
                        > From: Peter Williams <pezra@...>
                        > Subject: Re: [rest-discuss] HTTP request and "type safety"
                        > To: "Kevin Duffey" <andjarnic@...>, "Rest List" <rest-discuss@yahoogroups.com>
                        > Date: Saturday, March 13, 2010, 8:37 AM
                        >
                        > On Fri, Mar 12, 2010 at 9:57 PM, Kevin Duffey <andjarnic@...> wrote:
                        >
                        > > I am confused a bit about this. I was just thinking this today. If I
                        > > provide a single URI point of entry, and an OPTION or GET request is
                        > > sent, it returns some relevant links that can be called based on the
                        > > state of the resource. Now, to get those links, I have to first
                        > > access the point of entry URI. What happens if say a bot program (or
                        > > even a client developer) decides to cache/save these URIs that
                        > > return. Then at some point later, call those URIs directly instead
                        > > of the point of entry URI first to get those URIs back. They could
                        > > even navigate some links for a while, then save the various URIs
                        > > deeper down. Later, call those directly.
                        >
                        > A URI that is saved -- iow, bookmarked -- counts as an entry point
                        > URI. This sort of bookmarking is required to implement many kinds of
                        > systems composed of multiple components that expose REST style
                        > interfaces.
                        >
                        > Of course, there is no guarantee that URIs saved by a client will
                        > remain valid over time. Clients that save URIs must accept that the
                        > resources those URIs name may disappear as any point in the future.
                        > Well behaved servers do not disable URIs capriciously (see Cool URIs),
                        > but resources do have life-cycles that are governed by their domain.
                        >
                        >
                        > > My confusion of this is because the server side is stateless. It
                        > > retains no state. So how can I validate a URI that a client/bot
                        > > saved from some previous use, to make sure it's valid at the time of
                        > > call? I have no state on the server side that says "this URI is
                        > > being called BEFORE the URI that returns this URI was called.. it's
                        > > a bad call". So I am unsure as to how to validate every single URI
                        > > call to make sure it was called at a time when it should be called,
                        > > and not just randomly out of order. I suppse we can use some sort of
                        > > timestamp on every single URI that goes back, not sure entirely how
                        > > that would work at this point, but I suppose the server would check
                        > > this value when it came back in to the current server time stamp and
                        > > make sure it's within so many minutes of when it was issued. But a
                        > > smart client developer/bot could possibly figure that out, and
                        > > update this value before making the request, and since the server
                        > > keeps no state, if the modified timestamp is within the right time
                        > > of the server, it would void that route of validating a URI.
                        >
                        > Why do you care if the resources are accessed "out of order"?
                        >
                        > If there are domain reasons for a resource to be available for a
                        > limited time, the application logic should destroy/deactivate the
                        > resource once it is no longer valid. In that case, this hypothetical
                        > client with get a 410 or 404 when it attempts to make requests of the
                        > now nonexistent resource.
                        >
                        > If there is no domain reason for the resource to expire why is it a
                        > problem for a client to save a URI and the access it later?
                        >
                        > Peter
                        > http://barelyenough.org
                        >
                        >
                        >
                        >
                      • Nick Gall
                        Kevin, This issue of entry point URI vs. comes up from time to time. Here is a post from a while ago from the middle of a previous
                        Message 11 of 18 , Mar 14, 2010
                        View Source
                        • 0 Attachment
                          Kevin,

                          This issue of entry point URI vs. <<some other type of URI>> comes up from time to time. Here is a post from a while ago from the middle of a previous discussion of the issue. Roy schooled me one the subject. :-)


                          Re: [rest-discuss] Newbie REST Question

                          On Fri, Oct 2, 2009 at 12:21 AM, Roy T. Fielding <fielding@...> wrote:
                          >> Where do you get the idea that not all URIs need be or should be cool? (If I am understanding you correctly...)
                          >
                          > Umm, maybe the several hundred conversations I've had on
                          > the topic with TimBL in the room.  Cool URIs are permanent,
                          > so if you want to be cool then make permanence a design
                          > criteria.  That's all there is to it. 

                          Agreed.

                          > Nobody is going to
                          > argue against too much URI permanence.  There is certainly
                          > nothing about that in conflict with REST, so if you perceive
                          > a conflict then I suggest you look at your reasoning and
                          > kill the paper tiger.

                          I'm glad to hear you confirm that there is no real conflict between URI permanence and REST. I'm also glad to hear you confirm that there is no real conflict between designs that depend on URI permanence and REST, eg out-of-band URI templates. (Which is how I read your other reply.)

                          While others may use the word "conflict", for the record, I don't believe I used the word "conflict" in this thread -- I used the word "tension". And I quoted an email of yours from back in February that seemed to indicate that you did not completely disagree with the "tension" characterization:

                          If there is a tension between the desire to bookmark and the fact that REST encourages folks to break up an application into a state machine of reusable resource states, then I would consider it to be more like sexual tension. Just because you have it doesn't mean it is bad, and one way to improve things is to make the more important resource links look sexier than the less important ones.

                          I suppose the fundamental tension here (and perhaps in sexual tension as well -- who knows) is the tension between the desire for permanence and stability vs. the desire for adaptability and change.

                          -- Nick


                          Nick Gall
                          Phone: +1.781.608.5871
                          Twitter: ironick
                          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/


                          On Sun, Mar 14, 2010 at 11:50 AM, Kevin Duffey <andjarnic@...> wrote:


                          Hi Peter,

                          As for why I care.. I don't.. I thought it would not be HATEOAS if a URI could be accessed directly and not "discovered"? From all the posts, it seemed to me that if you accessed any URI directly, and not via an initial URI entry point that then gave you URIs you could use based on the resource state, I figured that was not the HATEOAS/REST way. I couldn't figure out how you could actually validate that a URI was called based on a URI you passed back previously, given the no state restraint in terms of resources on the server side.

                          I suppose tho, that a client should not save URIs for future direct access, as data may change, even resources could change, hence the ability to evolve the server side without breaking the client.


                          --- On Sat, 3/13/10, Peter Williams <pezra@...> wrote:

                          From: Peter Williams <pezra@...>
                          Subject: Re: [rest-discuss] HTTP request and "type safety"
                          To: "Kevin Duffey" <andjarnic@...>, "Rest List" <rest-discuss@yahoogroups.com>
                          Date: Saturday, March 13, 2010, 8:37 AM


                          On Fri, Mar 12, 2010 at 9:57 PM, Kevin Duffey <andjarnic@...> wrote:

                          > I am confused a bit about this. I was just thinking this today. If I
                          > provide a single URI point of entry, and an OPTION or GET request is
                          > sent, it returns some relevant links that can be called based on the
                          > state of the resource. Now, to get those links, I have to first
                          > access the point of entry URI. What happens if say a bot program (or
                          > even a client developer) decides to cache/save these URIs that
                          > return. Then at some point later, call those URIs directly instead
                          > of the point of entry URI first to get those URIs back. They could
                          > even navigate some links for a while, then save the various URIs
                          > deeper down. Later, call those directly.

                          A URI that is saved -- iow, bookmarked -- counts as an entry point
                          URI.  This sort of bookmarking is required to implement many kinds of
                          systems composed of multiple components that expose REST style
                          interfaces.

                          Of course, there is no guarantee that URIs saved by a client will
                          remain valid over time.  Clients that save URIs must accept that the
                          resources those URIs name may disappear as any point in the future.
                          Well behaved servers do not disable URIs capriciously (see Cool URIs),
                          but resources do have life-cycles that are governed by their domain.


                          > My confusion of this is because the server side is stateless. It
                          > retains no state. So how can I validate a URI that a client/bot
                          > saved from some previous use, to make sure it's valid at the time of
                          > call? I have no state on the server side that says "this URI is
                          > being called BEFORE the URI that returns this URI was called.. it's
                          > a bad call". So I am unsure as to how to validate every single URI
                          > call to make sure it was called at a time when it should be called,
                          > and not just randomly out of order. I suppse we can use some sort of
                          > timestamp on every single URI that goes back, not sure entirely how
                          > that would work at this point, but I suppose the server would check
                          > this value when it came back in to the current server time stamp and
                          > make sure it's within so many minutes of when it was issued. But a
                          > smart client developer/bot could possibly figure that out, and
                          > update this value before making the request, and since the server
                          > keeps no state, if the modified timestamp is within the right time
                          > of the server, it would void that route of validating a URI.

                          Why do you care if the resources are accessed "out of order"?

                          If there are domain reasons for a resource to be available for a
                          limited time, the application logic should destroy/deactivate the
                          resource once it is no longer valid.  In that case, this hypothetical
                          client with get a 410 or 404 when it attempts to make requests of the
                          now nonexistent resource.

                          If there is no domain reason for the resource to expire why is it a
                          problem for a client to save a URI and the access it later?

                          Peter
                          http://barelyenough.org




                        • Jan Algermissen
                          Nick, ... I think you wrongly see a tension there. Server evolvability is not negatively impacted by URI permanence. You do not degrade the freedom of the
                          Message 12 of 18 , Mar 14, 2010
                          View Source
                          • 0 Attachment
                            Nick,



                            On Mar 14, 2010, at 10:01 PM, Nick Gall wrote:

                            >
                            > I suppose the fundamental tension here (and perhaps in sexual tension as well -- who knows) is the tension between the desire for permanence and stability vs. the desire for adaptability and change.
                            >

                            I think you wrongly see a tension there. Server evolvability is not negatively impacted by URI permanence. You do not degrade the freedom of the service owner to change the service by mandating cool URIs. All the server needs to do is to maintain the URIs (even if they return 301 or 410) and maintain the semantics of the resource they identify.

                            In fact, I think that those two things are the only elements of a Web application that a server *can* reasonably guarantee to keep stable and their stability allows the clients to maintain 'handles' (Bookmarks or 'open browser windows) to certain application states. This allows the client to efficiently jump back and forth between states to follow certain transitions. Freshness information and change notifications (303 See Other) allow the server to inform the client when it should refresh its views of these application states.

                            As a side note: it is a misconception about REST that a client can only use the current steady state to choose transitions. It can also go back in its own history to find certain transitions it is looking for. Likewise, it is perfectly fine to look at several steady states simultaneously to work towards some desired goal.


                            Jan
                          • jumeier@yahoo.com
                            First, thanks to all for contributing so many ideas in this extensive thread! ... From: Craig McClanahan Subject: Re: [rest-discuss] HTTP
                            Message 13 of 18 , Mar 16, 2010
                            View Source
                            • 0 Attachment
                              First, thanks to all for contributing so many ideas in this extensive thread!

                              --- On Wed, 3/10/10, Craig McClanahan <craigmcc@...> wrote:

                              From: Craig McClanahan <craigmcc@...>
                              Subject: Re: [rest-discuss] HTTP request and "type safety"
                              To: jumeier@...
                              Cc: rest-discuss@yahoogroups.com
                              Date: Wednesday, March 10, 2010, 12:45 AM



                              On Tue, Mar 9, 2010 at 9:48 AM, <jumeier@...> wrote:
                               

                              Hi all,

                              I have a customer who raised a concern about REST "type safety". What he means may be best explained by a simple example.

                              Assume we have a resource that represents a folder, and by issueing a POST request, I can attach a file. What, however, if that post request wrongly goes to, let's say, another document resource instead of our folder, and the document resource also accepts POST (for some reason)?

                              In a RPC world, the document type would not understand an "addDocument()" call, and consequently return an exception. But what about REST? Of course, the POST's attributes most likely wouldn't be understood and something like 400 Bad Request returned. But what if they were understood?

                              So, are there means or patterns, to achieve (some sort) of type safety?

                              This is one of the reasons I prefer to use specific media types, instead of generic things like "application/xml" or "application/json", for my resources.  Then, if your "folder" resource accepts a media type that says "here is a new document resource", but your document resource doesn't (it accepts some other kind of POST request like "here is a comment to add to the discussion about this document" with a different media type), then you're fine ... a 4xx response would be appropriate (and, if you're using a framework like JAX-RS for Java, the framework will take care of this negotiation for you).  An an extra for-free bonus, you can set things up so that the same resource can accept different POSTs (with different media types) to trigger different state changes and server responses.  No need to create 3 "artificial" resource URIs to support 3 different POSTs that trigger state changes.

                              >> Thanks for this interesting ideas with the media type. I made a similar observation - and now Roy will probably throw yet another frisbee - I looked at the new OASIS CMIS standard, more precisely at what they call "restful binding". This is based on HTTP and ATOM, with extensions. In the ATOM feeds/entries are number of attributes, that give certain hints on consistency, e.g. the doctype. But the problem I mentioned is solved as cmis:folder supports POST and no PUT, and document does exactly the contrary. Looks coherent to me.

                              >> As I am working mainly with Apache Sling, they introduced something called a "selector" as part of the URI. However, this controls renditions, thus applies for GETs only. But it's a good twist if you need radically different renditions from the same resource. E.g. /orders/123.list.html could provice a list with all line items, while /orders/123.tax.html may bring up information regarding tax calculations.

                              If you use a generic media type, then your "document resource" will need to validate the details of the received input to make sure it obeys the rules for what kind of behavior a POST should trigger on a document.  Of course, you should be doing that anyway ... so it should be pretty obvious that the incoming data doesn't have the right set of fields.  This kind of "form validation" isn't really much different than what you should be doing in a browser-based webapp, where the same scenario is possible.

                              >> Well, I definitely see that I can kiss goodbye the wonderful POST automisms from Sling...

                              Thanks so much,
                              Juerg

                              Craig


                            • jumeier@yahoo.com
                              ... Sorry to double check on this image, but IMHO, images are a very good mean to transport abstract things like REST to customers. So, it d prefer to have
                              Message 14 of 18 , Mar 16, 2010
                              View Source
                              • 0 Attachment
                                --- On Wed, 3/10/10, Roy T. Fielding <fielding@...> wrote:

                                > From: Roy T. Fielding <fielding@...>
                                > Subject: Re: [rest-discuss] HTTP request and "type safety"
                                > To: jumeier@...
                                > Cc: rest-discuss@yahoogroups.com
                                > Date: Wednesday, March 10, 2010, 1:53 AM
                                > On Mar 9, 2010, at 9:48 AM, <jumeier@...>
                                > <jumeier@...>
                                > wrote:
                                >
                                > > I have a customer who raised a concern about REST
                                > "type safety". What he means may be best explained by a
                                > simple example.
                                > >
                                > > Assume we have a resource that represents a folder,
                                > and by issueing a POST request, I can attach a file. What,
                                > however, if that post request wrongly goes to, let's say,
                                > another document resource instead of our folder, and the
                                > document resource also accepts POST (for some reason)?
                                > >
                                > > In a RPC world, the document type would not understand
                                > an "addDocument()" call, and consequently return an
                                > exception. But what about REST? Of course, the POST's
                                > attributes most likely wouldn't be understood and something
                                > like 400 Bad Request returned. But what if they were
                                > understood?
                                >
                                > Ah, yes, a similar thing happens all the time when
                                > flaying frisbee in the park with my dog.  When I
                                > throw
                                > the frisbee and the dog tries to catch it in his teeth,
                                > everyone seems to be happy.  However, when the dog
                                > tries
                                > to throw the frisbee and I try to catch it in my teeth,
                                > it just doesn't seem to work well for either of us.

                                >> Roy, I hope this email finds your dog well.
                                Sorry to double check on this image, but IMHO, images are a very good mean to transport abstract things like REST to customers. So, it'd prefer to have things clear.
                                So, you're suggesting that you are the server, the frisbee is the request, and the dog is the client? And *if* you are sending a bad message in the form of a poor shot or a very mal-formed frisbee, the dog won't be able to catch it? Thanks for clarification.

                                >
                                > > So, are there means or patterns, to achieve (some
                                > sort) of type safety?
                                >
                                > Yes.  A RESTful interface is one where the server
                                > provides the links
                                > or forms that tells the client what operations to perform
                                > where.
                                > If you are telling the client to do the wrong thing, then
                                > the
                                > pattern would be to tell the client to do the right thing
                                > instead.
                                > Generally speaking, it works out better that way.

                                >> Thanks for reminding me of the basic things in REST-life. Clearly the way to go.
                                This just raises me one question. How would you flag to the client a link that is cool and MAY BE persisted, versus one that is of transient nature?

                                Thanks,
                                -- Juerg


                                >
                                > ....Roy
                                >
                                >
                              • Roy T. Fielding
                                ... No, I was suggesting that the customer should not be seeking RPC solutions (like type-safety checks) to apply in a RESTful design where data is provided at
                                Message 15 of 18 , Mar 16, 2010
                                View Source
                                • 0 Attachment
                                  On Mar 16, 2010, at 3:05 PM, <jumeier@...> <jumeier@...> wrote:
                                  > Sorry to double check on this image, but IMHO, images are a very good mean to transport abstract things like REST to customers. So, it'd prefer to have things clear.
                                  > So, you're suggesting that you are the server, the frisbee is the request, and the dog is the client?

                                  No, I was suggesting that the customer should not be
                                  seeking RPC solutions (like type-safety checks) to apply
                                  in a RESTful design where data is provided at the direct
                                  instruction of the server. The scenario doesn't make
                                  any sense, unless of course the client isn't using REST
                                  at all and merely thinks that HTTP == REST.

                                  > This just raises me one question. How would you flag to the client a link that is cool and MAY BE persisted, versus one that is of transient nature?

                                  I would never use a transient link in the first place.
                                  Even my redirect links are persistent. Why do you need one?

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