On 20/01/07, Jan Algermissen <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
>
>
> On 20.01.2007, at 01:24, Gregg Wonderly wrote:
>
> > Jan Algermissen wrote:
> >> On Friday, January 19, 2007, at 05:26PM, "Gregg Wonderly"
> >> <[EMAIL PROTECTED]
> >> <mailto:gergg%40cox.net>> wrote:
> >>> I'm not sure what your looking for here. HTTP POST and RMI/JERI
> >>> INVOKE have the
> >>> exact same capabilities. You can send some content, it is acted
> >>> on by the
> >>> application on the other end, and you get something back. The
> >>> semantics on top
> >>> of either of those operations are defined by the actions of the
> >>> service that the
> >>> content is processed by.
> >>
> >> The key question is whether these additional semantics are visible
> >> to/understood by the client.
> >> In the case of REST they are not - the client only knows about the
> >> 'process this' semantics, no more.
> >
> > The additional semantics must be known by the client in order for
> > the developer
> > of that client to make the right choice of which operation to use,
> > how to wrap
> > the data and parameters that the resource understands etc.
>
> No, that is apparently your misunderstanding. The method is POST
> (process this) and the client does not know about any other
> semantics. Clients do have to choose the right resource to POST to
> (e.g. a shoe order processor) to get the desired result, but the
> operation is just POST.
So can you explain to me how a POST method would (semantically) handle
a record that said
<order>
<line>
<id>sdafsdf</id>
<quantity>4</quantity>
</line>
</order>
as opposed to
<order>
<id>123123</id>
<line>
<id>sdafsdf</id>
<quantity>5</quantity>
</line>
/order>
Because if all that is required is the semantics of POST then it
should be clear what is required. Could you then further explain the
semantics if 1 follows 2 v if 2 follows 1 as requests to the resource.
