Hi Sean,
> I should have mentioned that this is a web service so
> browsers don't need to
> be involved. Does that change anything?
No, if the HTTP client is somewhat limited regarding methods, the tunnel
service can still be used.
> 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.
CANCEL seems a bit too domain specific to become part of a uniform
interface. Would it be usable for resources other than invoices? The way I
would solve this would be to add a child resource InvoiceStatus for every
Invoice created. You could then simply GET/PUT this status (CREATED | ... |
CANCELLED).
> 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
>
> From a purely URI perspective, all I need is:
>
> router.attach("/orders/invoices/{invoiceId}", InvoiceResource.class);
>
> But the limited number of methods gets in my way. I think 1 &
> 2 should be a
> GET and 3 should be a POST.
>
> I could define a new URI, say,
> router.attach("/orders/invoices/{invoiceId}/cancel",
> InvoiceResource.class);
> but that seems unfortunate.
>
> Any suggestions?
I hope the above solution works for you.
Best regards,
Jerome
