Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

The Problem with Easy APIs

REST is rather vague about many of the specifics of its implementation


advertisement

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.



   

Jason Bloomberg is the leading expert on architecting agility for the enterprise. As president of Intellyx, Mr. Bloomberg brings his years of thought leadership in the areas of Cloud Computing, Enterprise Architecture, and Service-Oriented Architecture to a global clientele of business executives, architects, software vendors, and Cloud service providers looking to achieve technology-enabled business agility across their organizations and for their customers. His latest book, The Agile Architecture Revolution (John Wiley & Sons, 2013), sets the stage for Mr. Bloomberg’s groundbreaking Agile Architecture vision.

Mr. Bloomberg is perhaps best known for his twelve years at ZapThink, where he created and delivered the Licensed ZapThink Architect (LZA) SOA course and associated credential, certifying over 1,700 professionals worldwide. He is one of the original Managing Partners of ZapThink LLC, the leading SOA advisory and analysis firm, which was acquired by Dovel Technologies in 2011. He now runs the successor to the LZA program, the Bloomberg Agile Architecture Certification Course, around the world.

Mr. Bloomberg is a frequent conference speaker and prolific writer. He has published over 500 articles, spoken at over 300 conferences, Webinars, and other events, and has been quoted in the press over 1,400 times as the leading expert on agile approaches to architecture in the enterprise.

Mr. Bloomberg’s previous book, Service Orient or Be Doomed! How Service Orientation Will Change Your Business (John Wiley & Sons, 2006, coauthored with Ron Schmelzer), is recognized as the leading business book on Service Orientation. He also co-authored the books XML and Web Services Unleashed (SAMS Publishing, 2002), and Web Page Scripting Techniques (Hayden Books, 1996).

Prior to ZapThink, Mr. Bloomberg built a diverse background in eBusiness technology management and industry analysis, including serving as a senior analyst in IDC’s eBusiness Advisory group, as well as holding eBusiness management positions at USWeb/CKS (later marchFIRST) and WaveBend Solutions (now Hitachi Consulting).

Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap