It’s very common for people to add layers of abstraction in order to “decouple” components not realizing that all they are doing is hiding the coupling making it more difficult when things have to change. The phenomenon you’re trying to ignore is known as leaky abstraction in that there are some details you simply cannot abstract away and those that you cannot abstract away will leak into your abstraction layer. Anytime you offer a service you are implicitly defining a contract or API for those that want to use that service. Part of that contract will be how you present data to that service. You can’t abstract that detail away meaning that dependency though hidden, still exists. It leaks.
There is a rule that I’ve always though to be very sensible and that is, “the server owns the wire”. In other words, any service you offer should come with an API that clients can use w.r.t. the communication protocol you should decide to use. In this way you get to manage as many of the dependencies as is possible. That you are using REST should not be exposed to the users of the service. I know this isn’t a popular idea but… If you expose the communication protocol than it’s much more difficult to change the underlying communication protocol. If you “own the wire”, very easy to change things. As for messaging… it also causes implicit couplings between the client and the service provider. However, messaging implies the server owns the wire meaning you can easily change the communication protocol. I don’t see it as being any different than REST in that regards. Same with RPC. With traditional RPC, the frameworks will generate a client library which in turns implies you own the wire and thus have more control over the communication protocol. Kind regards, Kirk > On Aug 17, 2017, at 7:19 AM, 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 > <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] > <mailto:[email protected]>. > For more options, visit https://groups.google.com/d/optout > <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.
