3 ms·

I ~love~ REST! People who don't know anything about building distributed systems hop on the REST bandwagon and before you know it they've got a monstrosity tha

by terra_t 16y ago

I ~love~ REST! People who don't know anything about building distributed systems hop on the REST bandwagon and before you know it they've got a monstrosity that doesn't work. I come in as a $150 an hour consultant, explain really clearly that it's ~very~ hard to get business rules and transactions working right in a REST situation, re-architect the system with POX RPC and get it working. When I see blog entries about the "finer points of REST" I hear ka-ching, ka-ching, ka-ching!

borisk 16y ago
You're obviously (by your rate and believes) a newcomer to enterprise architecture ;) Distributed transactions are an anti-pattern even with WS-Transactions. And business rules belong to the services themselves, not to the service infrastructure.
- terra_t 16y ago
  That's the whole problem with REST; getting transactional semantics requires distributed transactions. In RPC you can do everything you have to do in a local transaction and package it as one RPC call. Fast and simple...
  - wanderr 16y ago
    If only SOAP wasn't the face of RPC to most people, you probably wouldn't get downvoted so hard. ;) SOAP is horrible but REST is worse. JSON-RPC is elegant and simple. I wish more people would use it.
mjw 16y ago
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.

by terra_t 16y ago

borisk 16y ago

You're obviously (by your rate and believes) a newcomer to enterprise architecture ;) Distributed transactions are an anti-pattern even with WS-Transactions. And business rules belong to the services themselves, not to the service infrastructure.

terra_t 16y ago
That's the whole problem with REST; getting transactional semantics requires distributed transactions. In RPC you can do everything you have to do in a local transaction and package it as one RPC call. Fast and simple...
- wanderr 16y ago
  If only SOAP wasn't the face of RPC to most people, you probably wouldn't get downvoted so hard. ;) SOAP is horrible but REST is worse. JSON-RPC is elegant and simple. I wish more people would use it.

mjw 16y ago

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.