WSO2, an open-source API management platform vendor, was one of the only open-source API product sellers to be reviewed in Forrester's 2014 report on API management vendors. But what developer pain points does this company aim to solve?
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
In this Q&A, Chris Haddad, technology evangelist at WSO2, talks about the features of his company's API management platform, including how it is changing API testing, how the company deals with legacy apps, and the expertise needed to work with its products.
What application development pain points are you hoping to solve?
Chris Haddad: We solve API design challenges. We provide API design tools, which are based on the Swagger 2.0 specification, which provides a design and coding environment to build API definitions. It also enables you to mock up the back-end response that the service behind the API would provide, so you can rapidly test out your front-end mobile clients or API consumer apps.
Additionally, it lets you set up sandbox back-end services and production back-end services, where you can point the platform to route the API traffic to a sandbox, a test system. Then when you're ready to go into production, at the flip of the switch, you'll start directing traffic towards the production system.
Also, one of the biggest challenges is in relation to versioning APIs. You need a platform and a mechanism to create, say, version two of an API. The easy way to do it, which our platform provides, is that you can simply clone the existing API and then make your modification. Then once you copy it over, you can determine if it is backwards compatible, and then you can specify that consumers who already have the keys to version one can access version two, just by simply changing the URL in their application.
If it's not backwards compatible and they would need to actually change their mobile app code to make changes based on the data structure that you're responding with or the required fields that you now enforce, then you can say, "Hey, look, guys. Your existing access keys for version 1.0 will not work in version 2.0. But hey, you can self-subscribe to version 2.0."
API platforms really lower adoption barriers because of the self-service features. You can go to our API store, which is very similar to a Google Play store or an Apple iTunes App Store, and you can view information about the API. You can read the documentation. You can look at the available service levels, the contract as to how that API will perform, generate access credentials that then you include in your application, and you can directly connect back to the API without any human conversation and interaction.
Are you able to work with a company to modernize legacy services?
Chris HaddadTechnology Evangelist, WSO2
Haddad: This would mean extending the reach and extending the availability and the reliability of any service that exists within the organization. Using what's called a facade pattern, we put a gateway in front of those back-end legacy services, and traffic is routed through our gateway. Our gateway understands a plethora of open connectivity protocols, whether it's traditional XML over HTTP, Java [Message] Service (JMS) or MQSeries.
So applications that have a service interface using a commonly accepted and adopted communication protocol can be accessed from our gateway. We just proxy and transfer the traffic back to the back-end service and then respond out to the calling application.
Are there ever times when a service or application is so old that you're just unable to work with them? And what do you do in that case?
Haddad: So the services and the legacy applications, they would need to have a usable service interface. Most of the applications, even if they were 15 years old, they usually do have an acceptable end-point mechanism, such as HTTP or just SOAP, the traditional Web services specification.
We also do even older legacy technologies, such as FTP or just file transfers. Now, those mechanisms do impact how you architect and design the response that the API would provide. In those situations, there [are] many times that we recommend to clients that they should build a new greenfield application to service the request.
So, it seems that using WSO2's technology requires a certain level of expertise on the side of the customer. What would be the minimum requirement that a company would need in order to take advantage of what WSO2 has to offer?
Haddad: It's very valuable to know RESTful design practices. So you still have to craft the RESTful URL. You still need to understand the request message and the response message that will be transferred via the API. Knowledge of the Swagger API definition format is helpful but not required. Knowledge of Web services in general and the understanding of API interaction patterns are also very helpful.
We usually interact with enterprise organizations with teams that have very complex requirements. So these guys are usually integration experts. REST has been around for, I guess, seven years now, so it's fairly well understood.
The platform does lower the required knowledge in relation to API security -- the ability to create access tokens, etc. Also, we streamline the application life cycle process, where you can very easily create, publish, deprecate and retire APIs by using Web-based workflow screens. It's a lot easier than hand-coding APIs and just deploying them using a base technology, such as JAX RS in the java world or JAX WS, and then trying to manage all your API definitions in spreadsheets. All of the scaffolding is provided by the platform, which really lowers the learning curve required.
Learn how API testing is evolving
Discover hop to ease API testing constraints
Get expert advice on handling API versioning issues
Learn how to secure REST API endpoints for cloud apps