On 11/12/06, Jan Algermissen <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
>
>
> On Dec 11, 2006, at 2:27 PM, Steve Jones wrote:
>
> > And how do you specify how the object's state will be manipulated?
>
> Huh? PUT's specification tells you how. The state will be replaced with
> the state you send.
So if I have an invoice resource which reads
<invoice>
<customer ref="/customer/DFSFS894325923" />
<id>12</id>
<value>123.32</value>
</invoice>
I can just replace this with
<invoice>
<customer ref="/customer/DFSFS894325923" />
<id>12</id>
<value>10</value>
</invoice>
Is that what you mean?
>
> > How do you tell the consumer the acceptable formats for the
> > manipulation of that state?
>
> With a form.
An example please....
>
> > How do you define requests that result in
> > the modification not of the resources state but in the state of a
> > related object?
>
> These request do not exist in REST.
>
> (Though you have POST ('process this') than can have any side effect
> you like.
These requests don't exist... except that they do. So you are saying
that a PUT statement is not allowed to effect the state of other
objects, but that a POST is.
> Again, hypermedia will tell you, what special things a POST acepting
> resource
> does (after all, the cient picks the resources it interacts with and
> that choice can
> be made with knowledge about the resources (see APP's feature
> extension).
Here is a real world example.
I "POST" a new order to the server, this results in the creation of an
invoice resource which refers to that order. Now the response to the
POST can contain the reference to GET the resource, but it is the POST
of order that created it. Equally the order will have created new
resources around shipping that are not accessible to the original
customer but which are accessible to the warehouse and logistics
company, so are NOT traversable from the response to the order.
So how do you do that in REST?
>
> >
> >>
> >> Honestly, why is this so hard to get across?
> >
> > Certainly a question given I've read the REST paper and heard this
> > line many many times, and even consumed a few REST resources (although
> > now Amazon isn't REST I've lost one of my reference points). You'd
> > almost think that I understood the GET/PUT bit and I was asking about
> > how the resources themselves would be documented so you can document
> > how all the various required transition requests can be compressed
> > down into four basic request types.
> >
> > I'm equally stunned that people struggle with the difference between
> > invocation and application. POST/PUT are not sufficient to say how
> > REST will implement a complex resource like inventory to enable
> > different types of inventory management to be implemented.
> >
> > Tell you what would help, show me how a URI and PUT/GET/POST/DELETE
> > are sufficient for inventory management of a complex supply chain
> > without requiring ANYTHING that isn't in standard HTTP. This means
> >
> > 1) Just standard HTTP MIME types
> > 2) No XML Schemas
>
> Noone said you do not need more mime types to do this. What makes you
> think so?
No I think you need both MIME types and Schemas, its you who is
arguing that there are standard MIME types to solve these problems.
I'm now realising this is wishful thinking rather than discussing what
actually exists. Its like me saying "Just use WS-Contract to define
your business SLAs and WS-SLA for the non-functionals".
>
> >
> > If REST has a uniform application interface that consists ONLY of that
> > defined in HTTP then this should be sufficient. If however you
> > require additional elements such as MIME types or XML Schemas then it
> > isn't and there are additional elements that are required to fully
> > specify the application/service level interfaces.
>
> Think
>
> public Status PUT(void*payload)
>
> ....the payload semantics are not part of the interface.
Oh boy.... I'll try again.
For a CLIENT and for the SERVER the payload is the bit of the
interface that ACTUALLY DOES something. It is also false to say that
Status is returned alone as Status is just the code, there is also a
payload which is returned from the invocation.
I know this might be hard to grasp, but I can handle the concept of a
PUT method, what I can't handle is PUT being utlimately generic and
independent of payload when its the payload that actually results in
the action, with the mechanism (PUT/GET/etc) just defining the form of
that action.
>
> They can change based on the current capabilities of client and server.
>
> Jan
>
> >
> > Hint: HTML/HTTP uses more than just HTTP.
> >
>
>
