REST and Reliable Messaging
Just came across a very good article by Marc de Graauw over at InfoQ on why WS-RM is useless. His main point being that usually when you have reliable messaging requirements, they should be handled at the business logic layer rather than at the “transport layer”. I encountered some similar issues earlier this year when designing a REST-based federated incident ticketing architecture. A couple of the use cases that had to be supported were to allow one ticketing system to create/assign a ticket to another ticketing system as well for one ticketing system to make updates to a ticket in another ticketing system. It was a requirement that these assignments and updates were guaranteed to make it from one system to another, e.g. otherwise the assignee may not get the ticket and would not work to resolve the incident. One of the biggest arguments about REST is the lack of support for reliable messaging but this did not prove to be a problem because the design addressed it at the business logic level. The ticket creation/assignment was implemented by POSTing a representation of the ticket to the target system while the ticket update was implemented by PUTing an updated representation of the ticket to the target system. Ensuring that the update always made it through to the target system was easy because the PUT operation in HTTP is idempotent so we could keep resending if we didn’t get a successful response code. Ensuring that the creation/assignment always made it through was not as simple but still was not difficult. Because POST is not an idempotent operation in HTTP we couldn’t simply just resend if we didn’t get a successful response code, otherwise multiple duplicate tickets would get created in the target system. To address this, we just included the source system’s ticket id in the representation that’s sent in the POST request and added a bit of logic in the target system’s implementation to first check and see if it already has a ticket with that source system id before creating. Now we could do the same thing that we were doing with the update ticket operation to ensure that the creation/assignment always made it through, i.e. resend until we got a successful response code without worrying that duplicate tickets would be created in the target system. So there you go–who needs some stinkin WS-RM!