On Oct 2, 2006, at 8:37 AM, Mark Baker wrote:
> On 10/1/06, Roy T. Fielding <fielding@...> wrote:
> > Well, so do I. Self-descriptive means that the type is registered
> and
> > the registry points to a specification and the specification
> explains
> > how to process the data according to its intent.
>
> Ok, which one is it? 8-)
>
> "REST enables intermediate processing by constraining messages to be
> self-descriptive: interaction is stateless between requests, standard
> methods and media types are used to indicate semantics and exchange
> information, and responses explicitly indicate cacheability."

Both. That is just a summary. The real constraint you are looking
for is under 5.2.1:

REST provides a hybrid of all three options by focusing on a
shared understanding of data types with metadata, but limiting
the scope of what is revealed to a standardized interface.
REST components communicate by transferring a representation of
a resource in a format matching one of an evolving set of standard
data types, selected dynamically based on the capabilities or
desires of the recipient and the nature of the resource. Whether
the representation is in the same format as the raw source, or is
derived from the source, remains hidden behind the interface. ...

This is one of those gray areas of increasing RESTfulness that will
doubtless drive some people nuts. The problem is that I can't say
"REST requires media types to be registered" because both Internet
media types and the registry controlled by IANA are a specific
architecture's instance of the style -- they could just as well be
replaced by some other mechanism for metadata description.

The broader question is what does it take to create an *evolving*
set of standard data types? Obviously, I can't say that all data
types have to be *the* standard before they are used in a REST-based
architecture. At the same time, I do require enough standardization
to allow the data format sent to be understood as such by the
recipient. Hence, both sender and recipient agree to a common
registration authority (the standard) for associating media types
with data format descriptions. The degree to which the format chosen
is a commonly accepted standard is less important than making sure
that the sender and recipient agree to the same thing, and that's
all I meant by an evolving set of standard data types.

Sure, it is easier to deploy the use of a commonly understood data
format. However, it is also more efficient to use a format
that is more specifically intended for a given application.
Where those two trade-offs intersect is often dependent on the
application. REST does not demand that everyone agree on a single
format for the exchange of data -- only that the participants in the
communication agree. Beyond that, designers need to apply their
own common sense and choose/create the best formats for the job.

If we want to call one more RESTful than the other, then we have
to take the goal of evolution into account. I would say it is more
RESTful to use a specific standard type when applicable or to define
a new type that is specific to a given purpose AND intended to be
standardized for that application type (i.e., proprietary types are
less RESTful than industry-wide standard types, but new standard
types are not less RESTful than old standard types). But that is
really only my personal preference, since the style does not
constrain REST-based architectures to a single standard.

....Roy