Re: Self-descriptive messages

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