Re: REST and DELETE?

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.

>
> 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?  While there are no "degrees" it's fundamental that a media type
be declared, registered, and suitable for a hypertext-driven API.

>
> 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.
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.

>
> 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?

>
> 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

You can't just redefine "visibility" to mean what you want it to mean,
as I've repeatedly tried telling you.  Your response is always
personal, i.e. my "shameful long-winded verbose design approach" and
your previous comments about how *you* prefer systems that actually
work. Well, I like systems that work, too, which is not mutually
exclusive of implementing REST's constraints as you continually infer
in your posts.

-Eric