On 12 Apr 2007, at 18:19, Sean Landis wrote:
The result of a CANCEL is that an invoice is canceled in the DB but
still
available. I don't think it is a useful new method in the sense
that MOVE
is. I see 'cancel' as a resource state change that should be a POST
(although we don't need to post any data). A
DELETE doesn't seem right since we aren't deleting the invoice,
just marking
it as canceled.
Others don't see it that way. I don't see CANCEL adding any new
behavior so
it's hard for me to justify.
More detail. We have three operations on an invoice (that is created
elsewhere).
1. Get invoice (GET)
2. Compute canceled invoice and return the savings
3. Cancel invoice
How would it be visible in the resource that it has been cancelled
afterwards? Can't you POST or PUT to that sub-resource?
In my application, I have a field status in the XML, also accessible
as subpath /status. In that case you can just post CANCELLED to that
path. So in some kind of short form:
GET /orders/invoices/13
Content-Type: text/xml
<invoice ..>
<blah>..</>
<bluh>..</>
<status xlink:href='/orders/invoices/13/status'>Processing</status>
</>
GET /orders/invoices/13/status
Content-Type: text/plain
Processing
POST /orders/invoices/13/status
CANCELLED
204 No Content
GET /orders/invoices/13/status
Content-Type: text/plain
Cancelled
(Notice how in this example it is ignoring the case of the status to
illustrate that we are not talking about free text)
Not sure about the 204 return..
Alternatively, POST the changed part of the resource back:
POST /orders/invoices/13
<invoice ..>
<status xlink:href='/orders/invoices/13/status'>Processing</status>
</>
or form encoded: "Status: Processing"
--
Stian Soiland, myGrid team
School of Computer Science
The University of Manchester
http://www.cs.man.ac.uk/~ssoiland/
