On 11/12/06, Jan Algermissen <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
>
>
> 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.
So its acceptable for the client to change the value of the invoice?
Not it isn't. So what you meant to say was that I can _request_ the
state change but the server will reject it and give back a return code
that tells me I tried to modify an unmodifyable resource.
I can also of course put
<biscuit>
<flavour ref="/pingu/DFSFS894325923" />
<id>F</id>
<value>Blue orange</value>
<fingle>Doo dad</fingle>
</biscuit>
And get another error. But how do I know what is right?
>
> >>
> >>> 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>
And a business example?
>
> >>
> >>> 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.
So both PUT and POST can impact the state of other objects, but only
if you do a POST will you know that your order can go through. If you
"PUT" an order you can't expect the order to complete...
>
> >>>
> >>> 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.
Exactly my point, this is a gap in REST as it stands at the moment.
I'm glad we agree.
>
> > 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.
Please re-read that statement. Of course it does something it is the
bit that REPLACES the state, potentially. It is the request being
made to change state without the payload there is NOTHING to do.
Think of it this way, if the payload was loaded from disk, received
via monkeys or any other mechanism could the impact be the same?
Answer: yes. If a PUT request was received with a different payload
would the impact be the same? Answer: no.
>
> > 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.
Its an essential part of the "hypermedia state machine" as it says
what traversals can be done next.
>
> >
> >
> > 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?
Almost, its exactly what I write to disk, the content is the bit that
varies, without the content there is nothing for the disk writer to
do.
>
> > when its the payload that actually results in
> > the action,
>
> No. The action is PUT.
PUT(fred) != PUT(jane) therefore if PUT = PUT and jane != fred its
fred and jane that make the difference.
>
> > with the mechanism (PUT/GET/etc) just defining the form of
> > that action.
>
> What do you mean by 'form of action'?
PUT = request to change state
GET = request to read state
>
> 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.
I'm hoping you mean to "request the launch of the missle" because
surely REST has some decent security going on?
>
> There is no single interaction no mater how complex that you cannot
> get done with PUT and POST.
Ah the good old Church/Turing thesis, I'm not going to argue with
that... of course sometimes its insanely complex to reduce things to
single interactions, but it is always possible.
>
> --> 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>
So you agree that it is the PAYLOAD change that results in the
launching of the missile and not the PUT? As PUTting the original
payload would not have that effect.
>
> 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]
> >
>
>
