What is REST and why do we use it? Part 2: Loose Coupling

“Loose coupling” is the software engineering principle that says components of a software system should only interact with one another through well-defined interfaces. If one component changes, other components should not also need to change. The interface should remain the same. The operations of the component should be hidden inside a black box, so that when there are changes, those changes don’t impact other components.

Loose coupling is often articulated as the Law of Demeter, the principle of information hiding, separation of concerns, and a number of other related axioms. Usually, it is applied to functions and object methods, but it also applies to a REST interface. In fact, a REST interface separates concerns in two different ways.

Party in the Front, Business out Back

The first and most obvious way that REST encourages loose coupling is in the separation of the user interface front-end from the data processing back-end. This can be easily seen in single-page applications (SPAs) like Gmail. The application is a JavaScript program that runs in your browser, sending data back and forth to the server. Other clients (e.g. mobile apps) can also connect to the same server. The server and clients can be modified and improved without effecting each.

As an interesting side note, the nature of SPAs results in a different separation of concerns. Typically, data is sent in JSON format, which is a simple representation and doesn’t contain any formatting data. Formatting data (i.e. how the app looks) is typically provided by templates that are rendered by the SPA and the browser.

Every Endpoint is a Black Box

The second way that REST encourages loose coupling is by the use of endpoints for different types of data and operations. For example, an online store might have it’s products at /api/products and customers’ shopping carts at /api/carts. To add an item to the shopping cart, the client needs to send the product ID to the cart.

The client doesn’t know anything about how the endpoints operate internally, and it doesn’t need to. The endpoints could be on the same server, different servers, or even different continents. Likewise, the endpoints could save their data to different databases. One might be written in Java EE and the other in Node.js.

The real power here is that it provides a way to migrate the back-end technology without affecting any client programs. Imagine that both endpoints are originally implemented in Java EE connected to a MySQL database, and then the store decides that they need to transition to a different technology stack. First they implement the /api/products endpoint in Node.js with MongoDB for persistence. There’s probably some additional work on the back-end to get the databases talking to each other, but the important thing is that the clients and customers are completely unaffected. The transition is seamless. The store can transition the second endpoint whenever they are ready. This is a much easier change that rebuilding the entire stack on new technology.

Whether it’s front-end clients and back-end data-processing, or different endpoints on the back-end server, a good REST design allows you to loosely components all across your system.