Jan Algermissen wrote: > On 23.02.2007, at 19:46, Glen Daniels wrote: > > That seems to me to be a > > truism of computing in general, as much for REST as it is for SOA > > as it > > is for in-process usage of third-party code libraries. Thus I'm > > having > > trouble understanding what you're getting at here? > > If the semantics of a message are not self describing (== are > independent from the receiver side in all aspects) > and if in addition the receiver is beyond your control, you don't > know what you are effectively uttering when you > invoke the remote method. > > Having a uniform interface and standardized message types solves > that. Assuming the existence of an Order MIME type, > > POST /foo > Content-type: application/order+xml > > <order> > ... > </order> > > Means the same thing always and everywhere. You can look it up in the > HTTP Specs and the MIME type standard, > none of which are changeable by any of the parties. (That is what > self descriptiveness is all about). > > If the receiver could change POST to mean 'cancel' that would not be > the case. But with HTTP you cannot do that. > (of course the receiver can implement POST to result in a cancel, but > this does not change what you said - because > the true meaning of POST is not open to interpretation.
But it is perfectly open to implementation variation! There is absolutely nothing about HTTP or REST that guarantees that a correct implementation of the semantic meaning of your resource is carried out on the remote end. So, there are no additional guarantees that HTTP provides over any other mechanism over the network to something that you are not in control of. Specs are worthless unless you are in control of the implementation of those specs if we are talking about security and QOS and service guarantees. You are just trusting that the remote end is doing the right thing. Gregg Wonderly
