Hot on the heels of the announcement of the RESTful API Modeling Language (RAML) by the RAML working group, I am very happy to announce the general availability of APIkit.
APIkit consists of a set of open source Maven and Mule Studio-based tools that enable developers to be massively productive in creating well-designed REST APIs. APIkit features include the ability to take a REST API designed in RAML, automatically generate backend implementation flows for it, and then run and test the API with a pre-packaged console.
Get Ready to RAML
APIkit APIs are defined in RAML and are therefore RESTfull. To design a RAML API, you can take advantage of the RAML API Designer. This web based tool allows anyone with minimal knowledge of RAML to design REST APIs, it continuously presents you with the allowed syntax at any given point within the definition of the API. The tool also dynamically maintains an interactive console, reflecting the structure of the API. This console enables API designers to get instant feedback from potential consumers of the API through a web based UI. The following is a screenshot of the RAML API Designer.
As Uri Sarid (CTO at MuleSoft) explained in the previous post, the RAML API Designer is MuleSoft’s open source contribution to RAML. In the spirit of spreading the creation of delightful APIs, we host the RAML designer on APIhub for anyone to access.
With the RAML API Designer you can create a an API that delights your API consumers, but how will you implement the backend of the API? You could leverage any of your favorite programming languages or REST frameworks to ensure line-by-line compliance. But wouldn’t it be nice if you could just feed your RAML interface definition into a tool which would generate the stub implementation of your API automatically? Enter APIkit.
Let’s Implement an API!
Once you have designed your RAML interface, you can feed it into APIkit, using either our Mule Studio tooling or Maven – from here on in this blog post we will focus on the Studio tooling.
In Studio, you can start with the RAML file either using the new project creation wizard, or by adding RAML files to an existing project. Mocked implementation flows for your RAML files are auto-generated if you specify the file as part of the project creation wizard. If you did not, you can always use the ‘Generate Flows’ feature on any given RAML file or the entire project as shown below.
The mocking behaviour of the backend flows is simple:
-
If the the RAML-defined description of a resource-action pairing includes an example payload, any test calls to the flow return a response with the example as the payload and an HTTP-status code of 200 – OK.
-
If the RAML-defined description of a resource-action pairing does not include an example payload, any test calls to the flow simply return a response with an empty payload and an HTTP-status code of 200 – OK.
Routing of requests to Mule flows are performed by a new Mule component called ‘APIkit Router’. By default, the routing is done implicitly through naming: Flows named with a specific syntax that include the target resource and method name are used for routing associated HTTP requests. For example, GET: /patient calls automatically route to the flow named get: /patient:apikit-config.
However, you can override this routing if you would like to use a different flow naming scheme or if you would like to leverage existing flows that you might already have implemented. Below is a screenshot of the configuration wizard for the APIkit Router.
At any time, you can run your APIkit project to interact with its APIs using the built-in interactive console. To do this, just run the application as you would in any project and then browse to its console path (which you would have configured as part of the APIkit router component). Here is for example the console for the example football league project that is included in APIkit and available as a Studio example template.
RAML, APIkit, and Beyond!
As the attendees of our MuleSoft Summits can attest, we released APIkit as a private beta program early this year, introducing it then as part of our Spring MuleSoft Summit series. This GA version – APIkit 1.0 – is largely the result of the valuable feedback we have been receiving from our beta users. We have very exciting plans to add ever more value and functionality to APIkit such as improving the console’s UI, and updating the toolkit to ensure compliance with the latest version of RAML. Looking towards a broader horizon, we aim to add support for SOAP-based APIs in the future.
In the meantime, we encourage you to get your hands on APIkit! We’re certain it will prove an invaluable tool in increasing developer productivity for the design and development of APIs in your organization. Get started with APIkit, then test drive it with our APIkit tutorial. After just one taste, you’ll never design RESTful APIs any other way.
