Perhaps the most successful part of Representational State Transfer (REST) to date has been the simplification of Application Programming Interfaces (APIs). We no longer need a language-specific protocol that depends upon sophisticated network controls under the covers. Today we can take HTTP for granted, and a simple request to a URL suffices to establish any interaction we care to implement between any two pieces of software we like, regardless of language. What could be easier?
?Easy, yes, but with easy comes a dark side. If something?s easy, then anybody can do it. And if anybody can do it, then anybody will do it. And when that happens, you?re more likely to have chaos than orderly integration. And therein lie numerous, often unexpected problems.
REST, after all, is rather vague about many of the specifics of its implementation. Data formats, URI conventions, and how the hypermedia constraint is supposed to work, for example, are all subject to interpretation. As a result, many organizations have a plethora of different RESTful API styles, leading to incompatibilities, code maintenance issues, and even potential security risks.
For numerous vendors, of course, chaos means opportunity, and the API Management market is exploding as a result. You?d think as the API story shifted over the last decade from Web Services to RESTful interfaces that the core challenge would have become simpler. Au contraire: REST?s inherent flexibility has actually exacerbated the management headache, to the detriment of many IT shop?s API strategies.
The most obvious solution to the problem of easy APIs is to crack the whip. Establish rigorous, formal policies for how everyone must build their APIs, and then firmly enforce those policies. In other words, introduce governance into the development shop. Follow the rules or else!
Unfortunately, this heavy-handed approach to governance is usually counterproductive. It lowers morale and productivity among the development team, and can also limit the flexibility of the resulting software, which can adversely impact the agility of the organization.
What then is the best approach for managing the easy API problem, without falling into the traps of a management headache on the one hand or ?Big Brother? governance on the other? The answer: a well-architected balance between these two extremes.
By ?well architected? I mean first, that architectural decisions must be business-driven, and second, they must empower inherently flexible software ? in other words, Agile Architecture. Yes, API management tools, especially when they support a dynamic API abstraction, are an important enabler of Agile Architecture. But then again, so is an automated governance approach that encourages consistency in the application of API approaches while allowing flexibility. Bloomberg Agile Architecture strikes this balance. Learn more in an upcoming Bloomberg Agile Architecture Certification course.
