Re: Self-descriptive messages

<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 <[email protected]> wrote:

> On Aug 27, 2012, at 11:26 AM, Mark Baker wrote:
>
> > On Sun, Aug 26, 2012 at 3:10 AM, Bob <[email protected]> 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
>
>
>
>