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

Re: [rest-discuss] Self-descriptive messages

Expand Messages
  • Roy T. Fielding
    ... Well, that would only argue for a signature being exchanged instead of an etag (or just put the signature in the etag). IOW, it doesn t resolve the
    Message 1 of 13 , Aug 27, 2012
    View Source
    • 0 Attachment
      On Aug 27, 2012, at 11:26 AM, Mark Baker wrote:

      > On Sun, Aug 26, 2012 at 3:10 AM, Bob <bhaugen32@...> wrote:
      >> However, I thought of another reason that convinced me even more of the correctness of Mark's argument from a business standpoint, and that is non-repudiation: http://en.wikipedia.org/wiki/Non-repudiation
      >>
      >> That is, if both parties to an electronic agreement send, receive and sign each of the full messages exchanged in the dialog, maybe even exchanging the whole built-up sequence each time, they have a record of the agreement that would be difficult for either party to repudiate.
      >
      > Right. That was always in the back of my mind too, though as one
      > possible consequence of capturing the full meaning in a single digital
      > package.

      Well, that would only argue for a signature being exchanged instead
      of an etag (or just put the signature in the etag). IOW, it doesn't
      resolve the theoretical question.

      >> This reason may not have been Roy's reason for including self-descriptive messages as a REST constraint, but it would be important in business contract situations.
      >
      > I can't remember when or where, but I recall Roy talking about how
      > HTML documents needed their stylesheets and images in order to fully
      > reflect the intent of the publisher in a legal context. Not sure if
      > that was based on conjecture or actual case law though.

      Conjecture ... fidelity of reproduction is the essential element for
      legal documents, which is why certain forms of TIFF and PDF are
      officially recognized standards for archival forms. However, people
      in lawsuits present HTML all the time -- they just have to provide
      it in both rendered and plain text forms, and then call some witness
      to establish that the HTML would have matched the printed format
      when rendered by a typical browser at the time.


      No, I am not going to "settle" the philosophical question with an
      authoritative answer. I wouldn't learn anything if I did.

      I suggest folks worry less about that constraint (of visibility during
      a POST, which we already know isn't visible by nature) and more about
      what properties are lost by representation-by-reference. Most of the
      value cases for REST apply to repeatable responses, not an application
      that can't be reused, can't be transformed, and can't be shared.
      I do not believe in trying to apply all of REST's constraints unless
      there is a reason for doing so (aside from buzzword compatibility).

      My guess is that coupling would be more of a hazard than loss of
      visibility, but maybe even that wouldn't matter if the application is
      entirely driven via hypertext. It is really hard to get excited
      about the finer points of API design when the chosen method already
      says "do whatever you like with this".

      ....Roy
    • mike amundsen
      It is really hard to get excited about the finer points of API design when the chosen method already says do whatever you like with this . or
      Message 2 of 13 , Aug 27, 2012
      View Source
      • 0 Attachment
        <snip>
        It is really hard to get excited about the finer points of API design when the chosen method already says "do whatever you like with this".
        </snip>

        or (as I commonly see) an API design that says nothing at all about what you can do with this.

        mca
        http://amundsen.com/blog/
        http://twitter.com@mamund
        http://mamund.com/foaf.rdf#me




        On Mon, Aug 27, 2012 at 6:07 PM, Roy T. Fielding <fielding@...> wrote:
        On Aug 27, 2012, at 11:26 AM, Mark Baker wrote:

        > On Sun, Aug 26, 2012 at 3:10 AM, Bob <bhaugen32@...> wrote:
        >> However, I thought of another reason that convinced me even more of the correctness of Mark's argument from a business standpoint, and that is non-repudiation: http://en.wikipedia.org/wiki/Non-repudiation
        >>
        >> That is, if both parties to an electronic agreement send, receive and sign each of the full messages exchanged in the dialog, maybe even exchanging the whole built-up sequence each time, they have a record of the agreement that would be difficult for either party to repudiate.
        >
        > Right. That was always in the back of my mind too, though as one
        > possible consequence of capturing the full meaning in a single digital
        > package.

        Well, that would only argue for a signature being exchanged instead
        of an etag (or just put the signature in the etag).  IOW, it doesn't
        resolve the theoretical question.

        >> This reason may not have been Roy's reason for including self-descriptive messages as a REST constraint, but it would be important in business contract situations.
        >
        > I can't remember when or where, but I recall Roy talking about how
        > HTML documents needed their stylesheets and images in order to fully
        > reflect the intent of the publisher in a legal context. Not sure if
        > that was based on conjecture or actual case law though.

        Conjecture ... fidelity of reproduction is the essential element for
        legal documents, which is why certain forms of TIFF and PDF are
        officially recognized standards for archival forms.  However, people
        in lawsuits present HTML all the time -- they just have to provide
        it in both rendered and plain text forms, and then call some witness
        to establish that the HTML would have matched the printed format
        when rendered by a typical browser at the time.


        No, I am not going to "settle" the philosophical question with an
        authoritative answer.  I wouldn't learn anything if I did.

        I suggest folks worry less about that constraint (of visibility during
        a POST, which we already know isn't visible by nature) and more about
        what properties are lost by representation-by-reference.  Most of the
        value cases for REST apply to repeatable responses, not an application
        that can't be reused, can't be transformed, and can't be shared.
        I do not believe in trying to apply all of REST's constraints unless
        there is a reason for doing so (aside from buzzword compatibility).

        My guess is that coupling would be more of a hazard than loss of
        visibility, but maybe even that wouldn't matter if the application is
        entirely driven via hypertext.  It is really hard to get excited
        about the finer points of API design when the chosen method already
        says "do whatever you like with this".

        ....Roy

        ------------------------------------

        Yahoo! Groups Links

        <*> To visit your group on the web, go to:
            http://groups.yahoo.com/group/rest-discuss/

        <*> Your email settings:
            Individual Email | Traditional

        <*> To change settings online go to:
            http://groups.yahoo.com/group/rest-discuss/join
            (Yahoo! ID required)

        <*> To change settings via email:
            rest-discuss-digest@yahoogroups.com
            rest-discuss-fullfeatured@yahoogroups.com

        <*> To unsubscribe from this group, send an email to:
            rest-discuss-unsubscribe@yahoogroups.com

        <*> Your use of Yahoo! Groups is subject to:
            http://docs.yahoo.com/info/terms/


      • Jan Algermissen
        Hi Roy, thanks a lot for stepping in! ... FWIW, the cart/order scenario discussed is just a special case of the more general idea of action resources
        Message 3 of 13 , Aug 28, 2012
        View Source
        • 0 Attachment
          Hi Roy,

          thanks a lot for stepping in!

          On Aug 28, 2012, at 12:07 AM, Roy T. Fielding wrote:

          >
          >
          > I suggest folks worry less about that constraint (of visibility during
          > a POST, which we already know isn't visible by nature) and more about
          > what properties are lost by representation-by-reference.

          FWIW, the cart/order scenario discussed is just a special case of the more
          general idea of 'action resources' (body-less POST to an action-triggering
          URI), e.g.

          POST /cart?order
          Content-Length: 0

          Does your argumentation apply equally to the question of whether such
          'action resources' are suitable design?

          Or is there a fundamental difference between the cart URI being part of
          the body and the URI being the 'prefix' of the order-processor-resource?

          After all, both could be discovered from hypermedia equally well.

          Until now, I have used the self-descriptiveness constraint to argue against
          both designs.

          Since what you said makes sense to me, I am now in search for a new line of
          argumentation against POST /foo?triggerSomeStuffWithFoo

          A starting point for me would be that one design only uses a single ordering
          resource (/order-processor) while the other yields an unlimited number
          (/cart/{id};order)


          Can you give a hint?



          Jan




          > Most of the
          > value cases for REST apply to repeatable responses, not an application
          > that can't be reused, can't be transformed, and can't be shared.
          > I do not believe in trying to apply all of REST's constraints unless
          > there is a reason for doing so (aside from buzzword compatibility).
          >
          > My guess is that coupling would be more of a hazard than loss of
          > visibility, but maybe even that wouldn't matter if the application is
          > entirely driven via hypertext. It is really hard to get excited
          > about the finer points of API design when the chosen method already
          > says "do whatever you like with this".
          >
          > ....Roy
          >
          >
        • Tim Williams
          ... It s been a while, I ll take a stab... assuming it s truly a URL and not a URI... Performance - the server now has to do the de-referencing of a one or
          Message 4 of 13 , Aug 28, 2012
          View Source
          • 0 Attachment
            On Fri, Aug 24, 2012 at 10:14 PM, Darrel Miller <darrel.miller@...> wrote:
            > Mark,
            >
            > The interesting thing about the SKU scenario is that the URI may
            > actually capture the users intent more accurately than explicitly
            > stating the quantity. If the request body contains a URI that points
            > to http://aonlinestore.com/sku/jumbopackofshrimp then that maybe is
            > the exactly what that the user is requesting. The fact that this week
            > a jumbo pack of shrimp contains 10 shrimp and last week it contained 8
            > shrimp is irrelevant to the user because the identifier is specifying
            > what the user wants.
            >
            > I believe that to discount the my weathersnapshot scenario based on
            > the fact that I used a text/uri-list is addressing a different point.
            > I admit that I tend to be somewhat more cavalier about allowing the
            > server to pile on semantics to a message than I would ever allow a
            > client to do and I realize that't not a good idea. However, I believe
            > the point I was trying to make is just as valid if I were to use
            > application/vnd.acme.list-of-uris-to-weather-images.
            >
            > What are negative effects of allowing a server to dereference a link
            > contained in the request to acquire all the information necessary to
            > process the request?

            It's been a while, I'll take a stab... assuming it's truly a URL and
            not a URI...

            Performance - the server now has to do the de-referencing of a one or more URLs.

            Complexity - the order example requires a transaction and
            de-referencing adds to the list of things that can go wrong.

            Understandability - from a client perspective, it's less
            understandable - guarantees that key attributes (e.g. price) of the
            target resource hasn't changed and the like. maybe that could be
            covered by some 'purchasing protocol' or somesuch?

            Reliability - if the URL needs to be de-referenced and that server is
            unresponsive, your whole system is down.

            Visibility - moot, because of POST.

            Some are admittedly a stretch:) What are the advantages?

            Thanks,
            --tim
          Your message has been successfully submitted and would be delivered to recipients shortly.