This week’s release of the APIkit from MuleSoft offers API developers access to a suite of open source tools starting with API consumer-facing design and extends to a backend connection with an enterprise’s business logic layer and resources. Built for the open source RAML specification, Reza Shafii, Director of Product Management at MuleSoft, told ProgrammableWeb how API developers were crucial to the product design, and why open source solutions are growing in popularity amongst enterprise and business customers.
“We find that many customers are trying to design simple and elegant APIs in a concise manner, and then need a way to get quickly started on the implementation,” Shafii told ProgrammableWeb. (Disclosure: MuleSoft is the parent company of ProgrammableWeb.com)
APIkit lets developers use MuleSoft’s free API Designer interface to design an API, and then APIkit kicks in and helps implement the backend connection, all binded to the open source language RAML. Shafii says MuleSoft identified the need from developers who wanted to integrate their newly-created APIs quickly into their business systems, but often found they needed to redefine resources at the backend in order for the API to make calls and carry out functions.
“The use of APIkit consists of two phases,” Shafii said. “First, it creates a mocked backend logic that can get going right off the bat. It lets potential API consumers play with a console in which they can test a developer’s newly created API. The second phase is that it helps developers identify and then address the backend business logic one resource at a time.”
Shafii gives the example of a hospital admissions API. Even if it has only a few resources – such as a patient record – the API may still need to integrate with multiple backend systems including a customer database, billing systems, etc. APIkit allows for the design of the API to happen straightaway and for the implementation of its backend to happen separately
The APIkit has been in private beta development since March and has been redesigned to take on board two features in particular that were specifically requested by initial users to incorporate higher quality, scalable API design elements.
“Initially, the interface for the backend implementation was different than the interface on the API Designer, but developers wanted the runtime interface to look the same as the designer interface,” Shafii said. Shafii believes that using RAML makes it a great fit when using the same interface across the API development process.
“The concept of traits was also suggested by our beta users. The idea is that you can take certain aspects of your API, and use it across future API designs. For example, a paging trait could have a URL parameter that says the number of pages and the starting page number. This could be defined as a trait and used across subsequent APIs developed by that enterprise. It allows propogation of the same patterns and encourages best practice traits across the enterprise during API library development.”
The accessibility of an open source RAML language has been matched by a new wave of tools and platforms that support open source API development. Recent announcements including Zend’s Apigility Project and the launch of the API Commons are two examples.
“In the spirit of openness, we are contributing the java parser so it is available as open source”, Shafii said. “For customers, open source provides a level of transparency and lets enterprise developer teams better understand the tools and contribute to their development. For us, it is also about leveraging brainpower, and engaging a community around making contributions to API tool development.”