Well distributed transactions in some mission-critical enterprise setting isn't what REST is all about, not even close. If people are really making that mistake fair play to you.
I would hope that the majority of us out there using REST have a sense of perspective about it though. It's about providing services as part of the open web in a loosely coupled, organic, discoverable fashion based on standardised media types. And also about implementing lightweight APIs which observe the semantics of HTTP rather than layering stuff on top of it.
This kind of stuff is a great fit for a lot of APIs which face the open web, or which are used by clients without hard, business-critical constraints on reliability and transactionality. The semantics of HTTP obviously weren't designed for that stuff, although they do contain some features which go part-way towards helping, which is perhaps what sets some people on a slippery slope.
I would hope that the majority of us out there using REST have a sense of perspective about it though. It's about providing services as part of the open web in a loosely coupled, organic, discoverable fashion based on standardised media types. And also about implementing lightweight APIs which observe the semantics of HTTP rather than layering stuff on top of it.
This kind of stuff is a great fit for a lot of APIs which face the open web, or which are used by clients without hard, business-critical constraints on reliability and transactionality. The semantics of HTTP obviously weren't designed for that stuff, although they do contain some features which go part-way towards helping, which is perhaps what sets some people on a slippery slope.