Re: REST and DELETE?

On Wed, Aug 15, 2012 at 7:31 AM, Eric J. Bowman <[email protected]> wrote:
> Mike Kelly wrote:
>>
>> What part of the dissertation are you claiming this request would be
>> entirely non self-descriptive?
>>
>
> There are no "degrees" of self-descriptive.

Restating your own opinion is not a real answer to that question.
Sharing extracts or linking to a specific section would help.

>>
>> If youre being pedantic because I omitted Content-Type:
>> application/xml then please lets just pretend that was included in
>> the example.. Still not self-descriptive?
>>
>
> You're talking about self-descriptiveness and visibility and giving an
> example which fails to state a media type, or assumes application/xml.
> Do you not see where this might be confusing to folks trying to learn
> REST?

I didn't leave it out on purpose. I corrected myself. It is not that
big of a deal.

>>
>> It is self-descriptive to an extent: it's a non-safe request to the
>> cart resource to process the message in some way, it's a
>> cache-invalidating request.
>>
>
> Self-descriptive fundamentally means that you've declared a media type
> such that intermediaries can determine how to decipher the payload.

Yes, I forgot to include a Content-Type header, we've established that now.

The payload (request body) is one part of an HTTP request message,
there's also all the headers. GET requests don't have a payload or a
Content-Type and they're self-descriptive.

> You can't just hand-wave your way around this requirement by stating
> that it somehow isn't required for self-descriptiveness, that other
> factors are enough.

Yes, I forgot to include a Content-Type header, we've established that now.

>>
>> If you want to argue for superior self-descriptiveness, you need to
>> explain why the additional visibility you are creating will enable
>> otherwise-impossible intermediary mechanisms. Otherwise you should be
>> arguing some other system property than self-descriptiveness.
>>
>
> I don't know what "superior" means, I'm making an argument for the
> basics here, and I have no idea what "other" system property this would
> fall under.  I'm not creating "additional" visibility here, just
> stating the basic requirement for visibility.  If an intermediary can't
> determine how to process the payload, then anything else it can deduce
> about the message (cache-invalidating, non-safe, etc.) is useful, how?

well, for example, a cache that knows the request is
cache-invalidating and if it receives a success response from the
origin server the cache knows that it should purge on that URI.

Or a a security proxy that throttles write requests for clients can
increment its count for that client.

Or the request could include an If-Match header so that a cache knows
it's stale and respond with a 412 without having to hit the origin
server.

None of those intermediary mechanisms require the payload to be
processed, in fact processing the payload for those purposes would be
entirely redundant and incredibly inefficient.

>>
>> It seems to me like there is not a clear enough definition of
>> "self-descriptive" and/or visibility. And this results in it being
>> used as a go-to argument for anyone that prefers a long winded,
>> verbose design approach. Which is a shame.
>>
>
> There is, but apparently you don't much care for it, instead making
> semantic arguments about what else self-descriptive might mean, which
> seems to be your go-to argument for cutting corners on REST's
> constraints.  The rest of us have long since achieved consensus on the
> meanings of Roy's terminology.
>
> http://roy.gbiv.com/untangled/2008/specialization

That post is irrelevant. Please just share relevant quotes/links which
actually clarify the terminology in question.

Cheers,
M