Re: What is a SOAP Message

Well, I specifically reject the claim that

> So, I would prefer to reserve the term "representation"
> to refer to a set of data (typically a MIME-typed
> stream) that conveys some aspect of the state
> of a named Resource (I think I'd prefer to
> restrict this specifically to resources identified
> by URIs, though clearly similar systems could
> be built in other ways), and only in the case
> where access to such resources is modeled
> using the structures of REST (which is not
> necessarily HTTP, but necessarily builds
> on a view of GET, PUT, POST of
> representations as the means of manipulating
> and accessing a resource.)

since that simply isn't true for REST.  The semantics of a 
representation
in REST are defined by the control data (method, status code, and
sometimes media type).  REST is defined in this way because I want
to distinguish each type of data element within the architecture.
Message is just a convenient package defined by the protocol (an
implementation of REST).

Please note that this isn't subject to debate -- REST is defined
by my dissertation, not by consensus, which is why I regularly tell
the TAG that it isn't appropriate to say Web Architecture == REST
unless everyone wants to buy into my personal model of the HTTP/1.1
architecture as being the only Web architectural style, which
I don't believe is true, especially since that would make it hard
for me to explain the difference between Web-based applications
that suck and those that don't (they both already exist on the Web).
REST is supposed to guide protocol designers and application
developers so that they can implement in ways consistent with the
design of HTTP/1.1 and the desired properties of the Web; it cannot
constrain the Web architecture directly.

Most messages in HTTP can carry a payload and that payload is always
a representation of some resource as defined by the control data of
the message (not necessarily the Request-URI resource).  That is
clearly present in HTTP/1.1 when you look at the semantics of the
different HTTP status 2xx codes.

An HTML form is presented to the user in some UI-specific format.
That format is then translated upon submit into a representation
in one of a standardized media types (the common one being
the ugly "application/x-www-form-url-encoded") and transferred
to the HTTP server when using the method POST (the method of a
form was supposed to be extensible, but HTML4 screwed that up).
POST is effectively (though not exactly as written in 2616)
specified as "the resource is requested to process the enclosed
representation according to its media type and respond according
to the results of that processing."  Obviously, the same construct
can be defined for SOAP over HTTP, provided that it is consistent
with the defined semantics of the HTTP method and response code.

Does that make it RESTful?  No.  Any shared memory system by
message passing has no choice but to deal in representations,
though REST ones are further required to carry self-descriptive
metadata. REST also constrains that only resources can be identified,
actions are defined by methods, actions can only be applied to
resources, actions are stateless, actions are self-descriptive
(HTTP doesn't quite live up to this one), and the result of
actions is either the state of the identified resource or a set
of links that identifies the result set as resources
(e.g., search results in hypertext).  That's why REST stands
for Representational STATE Transfer.

So, yes, any payload of an HTTP message is a representation of
something, but that doesn't make SOAP any more or less RESTful
than it was before.  The result of an action is still not a
resource unless it is identified as one using a URI that is
(or will be) capable of processing a GET action accordingly.

....Roy

Received on Wednesday, 19 February 2003 21:15:40 UTC