Estamos teniendo un servicio REST WCF. queremos que la operación de guardado en este servicio REST esté en transacción. ¿Hay alguna manera de pasar el objeto Transaction por el cable al servicio REST WCF?Transacción en el servicio REST WCF
Aquí hay una cita de Roy Fielding, el tipo que inventó el término REST
Si usted se encuentra en necesidad de un protocolo transacción distribuida, entonces ¿Cómo se puede decir que su arquitectura se basa en REST? Me simplemente no puedo ver cómo se puede obtener de una situación (de la utilización de estado aplicación REST en el cliente y hipermedia para determinar todo el estado transiciones) a la siguiente situación de necesidad de acuerdo de distribución de la semántica de transacción en la que el cliente tiene que decirle al servidor cómo administrar sus propios recursos.
... por ahora considero que "transacción de reposo" es un oxímoron.
Se trata de un message en la lista REST-hablar desde el 9 de junio de 2009.
El soporte de transacciones en WCF se maneja por medio de una de las muchas normas WS- *, y esas solo se aplican a SOAP - dudo mucho que la webHttpBinding respalde las transacciones per se.
Es posible que desee comprobar en el ADO.NET Dataservices, que son una capa encima de WCF REST.
Vea un blog post del equipo ADO.NET DataServices acerca de esto.
Marc
Aquí es una discusión reciente sobre el tema: http://social.msdn.microsoft.com/Forums/en-US/adodotnetdataservices/thread/e66651c0-9202-4049-a8f4-55971b8b359d
Básicamente se dice: Una única petición no lo hace soporte de transacciones y no tiene sentido apoyarlas ya que solo una entidad y operación CUD está involucrada en una sola solicitud POST/PUT/DELETE. Pero las transacciones se pueden implementar en el lado del servidor en:
estoy básicamente de acuerdo con Roy Fielding citado en la respuesta de Darrel. Nunca debe exponer la plomería de la aplicación, como las transacciones de bases de datos a través de un servicio web RESTful. Sin embargo, podría abordar las transacciones distribuidas de una manera más funcional.
Supongamos que está implementando un sistema de punto de venta que puede recoger vales de regalo para compras. Los clientes deberían poder combinar los vales de regalo con los pagos con tarjeta de crédito. Tanto los cupones de regalo como los pagos con tarjeta de crédito son manejados por sistemas externos al punto de venta.Recolectar un vale de regalo y hacer un pago con tarjeta de crédito debería ser una transacción atómica. Para facilitar las cosas, centrémonos en un caso: los clientes primero recogerán el cupón de regalo y pagarán el resto del monto con su tarjeta de crédito. El pago con tarjeta de crédito puede fallar, por lo que también desea deshacer la colección de cupones de regalo cuando eso ocurra.
El servicio vale de regalo expone una URL para iniciar la recogida:
/gift-voucher/{gift-voucher-id}/collection
accediendo a esta dirección va a crear y persistir una reserva para el vale de regalo. La respuesta contiene una URL para la reserva:
/gift-voucher/{gift-voucher-id}/collection/reservation/${reservation-id}
Esta URL puede ser publicadas o borrado con el fin de ejecutar o cancelar la colección vale de regalo, respectivamente.
Tenga en cuenta que este enfoque solo se puede justificar para los servicios de aplicaciones donde hay un caso de uso funcional para revertir una transacción (es decir, el pago fallido con tarjeta de crédito). Intentar aplicar esto en servicios de nivel inferior como los servicios de la entidad probablemente requiera mucho trabajo y un rendimiento horrible. En este caso, puede preguntarse si un servicio RESTful realmente es la mejor opción.
Ok, entonces Fielding debería explicar (claramente, que es una tarea en sí misma) cómo se supone que le digo al servidor: cree estos dos recursos, pero al mismo tiempo, en lugar de crear primero este recurso, este otro recurso . –
POST/MyResourcePairs Le daré un ejemplo más real, pero encontrará que en la mayoría de los casos en que una transacción debe ocurrir, hay un nombre único que el usuario usa para referirse a ese evento. Por lo tanto, desde la perspectiva del usuario final, lo que describes rara vez existe. –
En otras palabras, violaría la restricción sin estado. – inf3rno