REST and RPC have good uses. But they are not a panacea. REST has implicit coupling because each HTTP request must have a corresponding HTTP response. Think of this as mandatory coupling from the protocol perspective. This implies that management between a request and its response must be done. (For retry, error, etc.). Whether you wrap that in a future or not is somewhat cosmetic. Web Services and the protocols attached to them are designed to try, as best they can, to decouple requests/processing/response.... but can't separate request and response from the HTTP perspective.
>From a higher perspective, HTTP can be made to look asynchronous from the request, response, and processing angles.... at the application level. However, most of the time, this is rarely done. Or done well. To allow full async communication, the basic communication block must be simplex (1-way) and not have response dependency at the application nor protocol level. This may seem that we are bashing on REST... and we are... somewhat. Mostly, though, we are bashing how REST is used. More like a hammer and everything is a nail. While in many cases, not nearly everything is a nail. And the hammer leaves a lot of "collateral damage" in the form of coupling and dependency that is unnecessary. For example, an extremely common problem with some systems using REST is throughput being restricted by RTT due to response coupling (application or protocol). On Wed, Aug 16, 2017 at 10:19 PM, Ziad Hatahet <[email protected]> wrote: > Martin mentions at 30:22 during his talk[1] that REST, while still better > than RPC, still causes coupling between communicating actors as opposed to > messaging. > > My question is: what's preventing REST calls from being wrapped in a > future or higher level messaging construct (e.g. Akka actor messages) such > that communication is decoupled because it becomes asynchronous? > > > [1] Beginning of discussion at https://www.youtube.com/watch? > v=oxjT7veKi9c&t=1805 > > Thanks, > > -- > Ziad > > -- > You received this message because you are subscribed to the Google Groups > "mechanical-sympathy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
