Re: REST and DELETE?

On Thu, Aug 9, 2012 at 10:41 AM, Dan Haywood
<[email protected]>wrote:

> **
>
>
>
> 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
>


Absolutely, key is that this is a design consideration rather than a
violation of any constraint.

Cheers,
M