Rest & Soap transactional capability -

in 1 interview, interviewer asked, transactional capability,out of soap , rest having transactional capabilities?

could please explain me in simple way.

thanks in advance,

had come across these references when ran similar questions. hope helps.

• from http://spf13.com/post/soap-vs-rest

  ws-atomictransaction need acid transactions on service, you’re going need soap. while rest supports transactions, isn’t comprehensive , isn’t acid compliant. fortunately acid transactions never make sense on internet. rest limited http can’t provide two-phase commit across distributed transactional resources, soap can. internet apps don’t need level of transactional reliability, enterprise apps do.

• from https://msdn.microsoft.com/en-us/magazine/dd942839.aspx

  what transactions?

  here area in soap , ws-* have explicit support "advanced" feature , rest has none. ws-atomic transactions supports distributed, two-phase commit transactional semantics on soap-based services. rest has no support distributed transactions. speaking, if want transactions in restful system, create new resource. (creating new resource whenever run problem restful system solves problems.) can have resource called transaction. when client needs transactional (such transferring money between 2 bank accounts), client creates transaction resource specifies correct resources affected (in example, 2 bank accounts) doing post transaction factory uri. client can perform updates sending put transaction uri , close transaction sending delete uri.

  this, of course, requires amount of hand-coding , explicit control on system, whereas ws-atomic transactions system more automatic because (in case of windows communication foundation) tied runtime's plumbing.

  if system absolutely needs atomic transactional semantics across diverse systems, ws-atomic transactions way go. using distributed transactions in way may or may not smart because increases coupling between 2 systems , creates potential problems if aren't controlling code on both ends. important thing use right tool right job (once you've figure out right job is). in defense of rest, think fair given today's distributed, service-oriented architectures, coupling 2 endpoints tightly using distributed transaction may not best design. on other hand, situations call type of functionality, , if need it, use soap , ws-atomic transactions.