RESTful reliability continued…
March 25th, 2007Stefan Tilkov has been doing a good job covering the ongoing discussion of how to do POSTs reliably.
All the solutions for a reliable POST seem ugly. Stefan ultimately suggests:
- POST to the
http://example.com/purchase-orders/newURI and have it return201 Createdand the URI for the new resource in theLocation:header.- PUT the intended content to the URI, possibly repeatedly in case of error.
While it has beauty in consistency, it seems less than ideal to require two invocations for an addition of a resource reliably.
On the other hand we have WS-RM. The nice thing about WS-RM is that it is transparent, even if it does take a message based approach instead of a resource based one. However, WS-RM is XML only. One of the major benefits of going down the RESTful route in my opinion is that works with any type of resource. This is one reason I don’t really see the WS-* and REST camps merging together.
March 26th, 2007 at 1:57 am
When a client is capable of generating a unique ID then that seems like the way to go…
http://www.goland.org/draft-goland-http-reliability-00.text
April 8th, 2007 at 5:58 am
ugly: yep, any reliable transmission over HTTP has to dela with its asymmetry - clients always initiate. The general theorem is that you need 5 steps to reach agreement on a transmission (and which can be compressed to 3). Physically on HTTP that maps to 2 requests. Models like BTF2.0 are perhaps more elegant, but require servers on either end.
client unique ids: problem is trusting clients. This will work for controlled scenarios, not general purpose web. Aside from trusting them to generate something suitably unique, ids are a potential spam vector. I guess most enterprise messaging is controlled to some extent and will have out of band agreements in place.
Another option is to “just dedup” on the server. It will give protocol formalists heartburn, but it works if you’re holding a long enough list of previously seen documents.