Abbiamo un servizio WCF REST. vogliamo che l'operazione di salvataggio su questo servizio REST sia in transazione. Esiste un modo per passare l'oggetto Transaction sul filo al servizio REST WCF?Transazione nel servizio WCF REST
Ecco una citazione da Roy Fielding, il tizio che ha inventato il termine REST
Se vi trovate nel bisogno di un protocollo transazione distribuita, quindi come si può forse dire che l'architettura si basa su REST? Io semplicemente non riesco a vedere come si può ottenere da una situazione (di usare RESTful stato applicazione sul client e ipermediale per determinare tutto lo stato transizioni) alla successiva situazione di che necessitano di un accordo distribuita di la semantica di transazione in cui il cliente deve dire al server come gestire le proprie risorse.
... per ora considero "transazione di riposo" come un ossimoro.
Questo è da un message sulla lista REST-discutere dal 9 giugno 2009.
Il supporto delle transazioni in WCF viene gestito mediante uno dei numerosi standard WS- * e solo per SOAP: dubito fortemente che webHttpBinding supporti le transazioni di per sé.
Si potrebbe voler controllare il ADO.NET Dataservices, che è un livello in cima a WCF REST.
Vedere un blog post dal team ADO.NET DataServices su questo.
Marc
Ecco una recente discussione sul tema: http://social.msdn.microsoft.com/Forums/en-US/adodotnetdataservices/thread/e66651c0-9202-4049-a8f4-55971b8b359d
In sostanza si dice: Una singola richiesta non lo fa supportare le transazioni e non ha senso supportarle poiché solo una entità e l'operazione CUD sono coinvolte in una singola richiesta POST/PUT/DELETE. Ma le operazioni possono essere implementate su lato server da:
io per lo più d'accordo con Roy Fielding citato in risposta di Darrel. Non si dovrebbero mai esporre tubature per applicazioni come transazioni di database attraverso un servizio web RESTful. Tuttavia, è possibile affrontare le transazioni distribuite in modo più funzionale.
Supponiamo che stiate implementando un sistema di punti vendita in grado di raccogliere buoni regalo per gli acquisti. I clienti dovrebbero essere in grado di combinare i buoni regalo con i pagamenti con carta di credito. Sia i buoni regalo che i pagamenti con carta di credito sono gestiti da sistemi esterni al punto di vendita.La raccolta di un buono regalo e il pagamento di una carta di credito dovrebbero essere una transazione atomica. Per semplificare le cose, concentriamoci su un caso: i clienti raccoglieranno prima il buono regalo e pagheranno il resto dell'importo con la loro carta di credito. Il pagamento con carta di credito potrebbe non riuscire, quindi è necessario effettuare il rollback della raccolta di buoni regalo quando ciò accade.
Il servizio buono regalo espone un URL per iniziare la raccolta:
/gift-voucher/{gift-voucher-id}/collection
Richiesta questo URL sarà creare e persistere una prenotazione per il buono regalo. La risposta contiene un URL per la prenotazione:
/gift-voucher/{gift-voucher-id}/collection/reservation/${reservation-id}
Questo URL può essere sia Posted o eliminati al fine di eseguire o annullare la raccolta buono regalo, rispettivamente.
Si noti che questo approccio può essere giustificato solo per i servizi applicativi in cui è presente un caso di utilizzo funzionale per il rollback di una transazione (ovvero il pagamento con carta di credito non riuscita). Cercare di applicarlo su servizi di livello inferiore come i servizi di entità implicherà probabilmente molto lavoro e prestazioni orribili. In questo caso ci si potrebbe chiedere se un servizio RESTful sia davvero la scelta migliore.
Ok, quindi Fielding dovrebbe spiegare (chiaramente, che è un compito in sé) come dovrei dire al server: creare queste due risorse, ma allo stesso tempo, invece di creare prima questa risorsa, quindi questa altra risorsa . –
POST/MyResourcePairs Vorrei darvi un esempio più reale ma troverete che nella maggior parte dei casi in cui una transazione deve verificarsi, c'è un singolo nome che l'utente usa per riferirsi a quell'evento. Pertanto, dal punto di vista dell'utente finale, ciò che stai descrivendo raramente esiste. –
In altre parole violerebbe il vincolo stateless. – inf3rno