On Dec 11, 2006, at 4:40 PM, Steve Jones wrote:
> 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?
>
>
Yes.
>>
>>> How do you tell the consumer the acceptable formats for the
>>> manipulation of that state?
>>
>> With a form.
>
> An example please....
>
Atom Pub. Protocol's <accept> element inside <collection>
>>
>>> 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.
No, I was a bit vague there. PUT is not defined to be side effect
free, but
the meaning of PUT is fixed. The client must not make expectations
beyond that.
PUT sets resource state, no more.
>>>
>>> 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 am saying that you need standard mime types. There are currently
none that
handle the sort of thing you are talking about.
> 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.
No. The payload represents resource state. It does not do anything.
> 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.
ok, there is payload - sometimes.
>
>
> 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
But that is what put is. it is just like writing a file to disk. That
is completely
independent of what you write, isn't it?
> when its the payload that actually results in
> the action,
No. The action is PUT.
> with the mechanism (PUT/GET/etc) just defining the form of
> that action.
What do you mean by 'form of action'?
If you want to create a missile POST to an appropriate resource (one
that you know will
create a missile)
You get back the URI of the new missile.
PUT a missile representation to that URI that has the missile state
set to 'launch' in order
to launch the missile.
There is no single interaction no mater how complex that you cannot
get done with PUT and POST.
--> POST /missiles
<missile/>
<-- 201 Created HTTP/1.1
Location: /missiles/8876
--> GET /missiles/8876
<-- 200 Ok HTTP/1.1
<missile>
<name>My Missile</name>
<state>StandBy</state>
</missile>
...manipulate XML...
--> PUT /missiles/8876
<missile>
<name>My Missile</name>
<state>Launching</state>
</missile>
Jan
>
>
>>
>> They can change based on the current capabilities of client and
>> server.
>>
>> Jan
>>
>>>
>>> Hint: HTML/HTTP uses more than just HTTP.
>>>
>>
>>
>
>
>
> Yahoo! Groups Links
>
>
> [EMAIL PROTECTED]
>
