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.
> How do you tell the consumer the acceptable formats for the
> manipulation of that state?
With a form.
> 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.
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).
>
>>
>> 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?
>
> 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.
They can change based on the current capabilities of client and server.
Jan
>
> Hint: HTML/HTTP uses more than just HTTP.
>
