The Importance of Loose Coupling in REST API Design
Loose coupling is not a new concept; however, it is one that is oft neglected in the world of REST API design. Find out exactly why this is and what can be done about it.
Join the DZone community and get the full member experience.Join For Free
one of the most important ideas in the world of software engineering is the concept of loose coupling. in a loosely coupled design, components are independent, and changes in one will not affect the operation of others. this approach offers optimal flexibility and reusability when components are added, replaced, or modified. conversely, a tightly coupled design means that components tend to be interdependent. changes in a single component can have a system-wide impact, with unanticipated and undesirable effects.
the value of loosely coupled systems is widely recognized in the software world, but unfortunately most mobile applications end up being tightly coupled to the rest api services that they use. each server-side api is often developed for a specific mobile application project. each new custom application then requires another special-purpose rest api. in other words, the application and the service end up being tightly coupled to one another.
developing a new rest api for every new project leads to backend complexity. over time, a company can end up with infrastructure that is not portable, scalable, reliable, or secure. i have written about the problem of developing new rest apis for every new project elsewhere, but now i think this warning should be even more strongly worded: companies should never develop a rest api for any specific application. please read that again, it’s a game changer. you should never develop a rest api for any specific application. this practice almost always results in an application that is tightly coupled to a custom-built service.
the best approach is to build a rest api platform that can be used and reused in a flexible manner for general-purpose application development. the advantages are enormous. for example, developers don’t need to learn a new api to develop a new application. the same apis can be reused for many different purposes. the total number of services and endpoints is consolidated, improving security. documentation, user roles, and api services become standardized, enhancing corporate governance and compliance.
when a mobile application is developed, there is usually a server-side team that builds the rest api and a client-side team that builds the application. the interaction between these two groups takes lots of time and money while they converge on an interface. in fact, gartner estimates that 75% of the cost of a mobile project is related to backend integration . and for this reason, the biggest benefit of a loosely coupled rest api architecture is that the interaction between these two teams is minimized.
this is where the concept of a loosely coupled rest api platform really generates business value. components that need to “know things” about each other are tightly coupled. components that can operate independently and have a well-defined communication channel are loosely coupled. in the same manner, if your server-side team is deeply engaged with your client-side team, then they are tightly coupled as well. these two teams can end up spending lots of time playing an expensive game of api ping-pong instead of shipping new applications.
as a veteran software engineer, i find one aspect of this situation rather fascinating. usually, loose coupling is just a best practice for object-oriented software design. if you leave some tightly coupled interfaces in the code somewhere, then the worst-case scenario is probably a few snarky comments from one of the other engineers over lunch. but in this situation, there are two distinct development teams and their interaction is defined by the rest api interface they are building. bad software design infects their working relationship, and this has real world consequences in terms of time and money.
a platform approach to restful services changes all of this. the server-side team focuses on mobilizing data sources, connecting legacy services, and administering role based security for the platform. the front-end team then builds anything they want on their platform of choice. problems are minimized because the developers automatically receive the services that they need. but what type of software can actually implement a system like this?
imagine that a modern developer could log into a portal, select the type of application that they want to build, and instantly get a comprehensive palette of rest api services designed for that purpose and vetted for use by their it department. this is a tangible roadmap for the modern enterprise to embrace loosely coupled design and take this vision to the next level by combining secure administration with agile platform oriented application development.
the new dreamfactory gold package provides this functionality. a company or service provider can host and manage hundreds or thousands of individual dreamfactory instances. each one is a complete rest api development platform. next, the administrators can define any number of pre-configured rest api packages for various purposes. examples might include services for iot, telephony, mobile applications, messaging, etc. these packages can include third party services like stripe or twilio, legacy soap services, and role-based access to any number of sql or nosql databases. all a modern developer has to do is sign up, select a package, and start building the client application.
this is where dreamfactory is headed. for us, api automation means instantly providing a comprehensive service based environment for modern developers on demand. use cases include exposing custom services to partners in a ready-made development environment and jump-starting enterprise developers with pre-loaded and pre-approved palettes of api services. this exciting new technology makes the benefits of loosely coupled rest api platforms a practical reality for the modern enterprise.
Published at DZone with permission of Bill Appleton, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.