We are having a REST WCF service. we want the save operation on this REST service to be in transaction. Is there a way to pass Transaction object over the wire to REST WCF service?
Here is a quote from Roy Fielding, the guy who invented the term REST
If you find yourself in need of a distributed transaction protocol, then how can you possibly say that your architecture is based on REST? I simply cannot see how you can get from one situation (of using RESTful application state on the client and hypermedia to determine all state transitions) to the next situation of needing distributed agreement of transaction semantics wherein the client has to tell the server how to manage its own resources.
...for now I consider "rest transaction" to be an oxymoron.
This is from a message on the REST-discuss list from June 9th, 2009.
I mostly agree with Roy Fielding quoted in Darrel's answer. You should never expose application plumbing like database transactions through a RESTful web service. However, you could approach distributed transactions in a more functional way.
Say you are implementing a point-of-sale system that can collect gift vouchers for purchases. Customers should be able to combine gift vouchers with credit card payments. Both gift vouchers and credit card payments are handled by systems external to the point-of-sale. Collecting a gift voucher and making a credit card payment should be an atomical transaction. To make things easy, let's focus on one case: customers will first collect the gift voucher and will pay the remainder of the amount with their credit card. The credit card payment may fail, so you also want to rollback the gift voucher collection when that happens.
The gift voucher service exposes a URL for initiating the collection:
/gift-voucher/{gift-voucher-id}/collection
Requesting this URL will create and persist a reservation for the gift voucher. The response contains a URL to the reservation:
/gift-voucher/{gift-voucher-id}/collection/reservation/${reservation-id}
This URL can be either POSTed or DELETEd in order to respectively execute or cancel the gift voucher collection.
Note that this approach can only be justified for application services where there is a functional use case to roll back a transaction (i.e. failed credit card payment). Trying to apply this on lower level services like entity services will likely involve lots of work and perform horribly. In this case you may wonder whether a RESTful service really is the best choice.
Transaction support in WCF is handled by means of one of the many WS-* standards, and those only apply to SOAP - I highly doubt the webHttpBinding will be supporting transactions per se.
You might want to check into the ADO.NET Dataservices, though, which are a layer on top of WCF REST.
See a blog post by the ADO.NET DataServices team about this.
Marc
Here is a recent discussion about the topic: http://social.msdn.microsoft.com/Forums/en-US/adodotnetdataservices/thread/e66651c0-9202-4049-a8f4-55971b8b359d
Basically it says: A single request does not support transactions and it doesn't make sense to support them since only one entity and CUD operation is involved in a single POST/PUT/DELETE request. But transactions can be implemented on server side by:
- using batch requests (a whole bundle of POST/PUT/DELETE requests being sent in one step from client to the server)
- and leveraging the processing pipeline (begin a transaction in the Processing event and commit/rollback the transaction in the Processed event)
© 2022 - 2024 — McMap. All rights reserved.