Rather than picking sides in the battle over API description languages, SOA Software has opted for the middle ground by adding support for RAML, Swagger, WSDL, and WADL to its API management platform.
Laura Heritage, director of API strategy for SOA Software, says rather than getting caught up in a religious battle, the simple fact is that organizations will wind up using different types of API description languages. In environments that are more driven from the top down, Heritage says SOA Software expects to see a lot more usage of RAML because it provides more structure. At the same time, Heritage says there are a larger number of individual developers that have embraced Swagger and it simply may not be feasible for IT organizations to mandate what API description language developers can use.
Heritage also notes that SOA Software is starting to see pockets of developers using API Blueprint to hypermedia frameworks to describe APIs.
SOA Software also supports WSDL and WADL (typically associated with legacy applications) to describe SOAP-based services. Heritage says many organizations are trying to bridge that gap between legacy applications and modern Web applications that support REST APIs using the same API management platform.
While the rise of API description languages has led to a lot more reliance on automation to generate APIs, Heritage says it is unlikely organizations will ever get to the point where 100 percent of an API is automatically generated using an API description language. There will always be some customization of the API required for a particular use case or to achieve higher levels of performance, says Heritage.
There will, however, be more automation of the API description language. SOA Software, for example, provides an AnySource Asset Adapter that integrates with its platform to generate an API description language from source code that can then be placed in the SOA Software Lifecycle Manager repository.
API description languages clearly have the potential to drive the API economy to a whole new level. Instead of having to invoke the services of developers to craft every aspect of an API, much of the core functions of the API can now be more rapidly generated. That should not only make it easier to develop more APIs faster, it should also give developers more time to customize those APIs as individual situations warrant. In fact, we may even see the rise of “citizen developers” using API description languages to generate APIs without the aid of professional developers.
In the meantime, rather than getting caught up in arguments over what API description language to use, it is starting to look like developers should simply be able to opt for the one that makes them most comfortable — regardless of what anyone else has to say about it.