Re: REST and DELETE?

I know this thread has gone far afield, but decided to interject this
anyway....

I am not at all convinced that the "self-describing" sub-constraint called
out by Fielding has anything at all to do w/ state (app, client, or
server). Instead, I assert that the "self-describing messages" (SDM)
constraint is applied at the protocol (HTTP, FTP, SMTP, XMPP, etc.) level.

IOW, SDMs exist w/o any "knowledge" of the problem-domain being expressed
by that message and SDMs have no role in assuring any problem-domain level
semantics, just network level semantics. Looked at another way, you can
have SDMs in a stateful arch model and you can have stateless arch model
where there are no self-describing messages.

mca
http://amundsen.com/blog/
http://twitter.com@mamund
http://mamund.com/foaf.rdf#me




On Fri, Aug 24, 2012 at 6:50 PM, Jan Algermissen <[email protected]
> wrote:

>
> On Aug 24, 2012, at 9:47 PM, Darrel Miller wrote:
>
> > Hey Mark,
> >
> >
> > Thanks for the response.  The first two examples were really kind of a
> lead in to the third which you didn't comment on.  Based on your
> explanation, it would seem that as long as the user is confident that the
> server isn't going to mess with their stored cart, then there is no reason
> why the user cannot request that the contents of their stored cart be
> ordered.
> >
> > The reality is that there needs to be a certain level of trust by the
> user in the service they are using.  Whether, the user-agent downloads the
> cart and re-posts it to an order processor, or the user-agent posts a link
> to stored cart, the intent of the user is the same and a user-agent can
> quite easily allow the user to preview the stored cart before posting the
> link to be ordered.  I fail to see how a message that refers to a resource
> loses its self-descriptiveness.
>
> Think about it this way:
>
> Because REST explicitly allows the server to independently change at any
> time, the messages sent by the client must be 'designed' to allow the
> server to detect any mismatch between the client's intent and what the
> server is about to do as a result of the request.
>
> POSTing an explicit cart much more meets that goal that POSTing a URI does.
>
> IOW, the semantics of the message (the deducable intended effect) must,
> under no cicumstances, be dependent on the nature of the recipient.
>
> Makes sense?
>
> Jan
>
>
>
> >
> > Regarding the need for the resource to be invariant is also a concern
> for me.  Consider the following processing endpoint that stores images of
> weather maps of cities.  If you post a text/url-list to it then it
> dereferences those urls and stores the resulting image.
> >
> > POST /WeatherSnapshots
> > content-type: text/url-list
> > http://weathernetwork.com/miami/currentweather
> >
> > I don't see the benefit of forcing all the extra data transfer required
> to do the following,
> >
> > GET http://weathernetwork.com/miami/currentweather
> > =>
> > 200
> > Content-type: image/jpeg
> > [bytes]
> >
> > POST /WeatherSnapshots
> > content-type: image/jpeg
> > [bytes]
> >
> > Imagine the scenario where several times a day a user wanted to take
> snapshots of many cities at the same time.  It would be far more efficient
> for the client to request that the server perform those requests on it's
> behalf than have the client download each than then post them back to the
> server.
> >
> > Sorry for belabouring the point but it is an issue that does comes up
> fairly regularly and when asked about it I don't like having to respond,
> "you aren't supposed to do this, but I don't understand why".  There's
> already enough dogmatic REST advice going around and I'd rather not
> contribute to it.
> >
> > Darrel
> >
> >
> >
> >
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>