Re: REST and DELETE?

On 9 August 2012 10:29, Mike Kelly <[email protected]> wrote:

> **
>
> > Until you consider the fact that the "buy" message has to contain all
> > that state since it contains the expectations of the user.
> >
> > http://www.markbaker.ca/blog/2007/11/users-and-self-description/
> >
>
> Does it _have_ to contain all the state? The following would work ok,
> and the important parts of the interaction are still visible:
>
> POST /cart/123
> If-Match: 2930480293842
> <state>reserve-to-pay</state>
>
>
Mike, I'm generally with you on this... basically some sort of optimistic
locking approach ought to be sufficient.

That said, I went off to read Mark's blog post, from which there were also
links off to some other interesting posts (especially Alan Dean, [1], [2],
[3]), who takes the same view as Jan.

On the second of those posts Stefan Tilkov made (what I thought was) a very
pertinent comment:

*I think this is a specific case of the general scenario where resources
are coupled behind the scenes. If they're part of the same "service",
that's fine; if they're not, it violates the idea of loose coupling.*
*
*
*In other words: If I define cart and order processing as being part of the
same application or service, I can use the approach you criticize. If I aim
to design them so they're independent, your alternative is better.*

I thought that was pretty insightful.
Dan

[1]
http://alandean.blogspot.co.uk/2008/11/when-basket-checkout-isn-restful.html
[2]
http://alandean.blogspot.co.uk/2008/11/what-restful-basket-checkout-might-look.html
[3] http://alandean.blogspot.co.uk/2008/11/on-restful-basket-state.html