MuleSoft With OpenAPI Specification

MuleSoft provides RESTful API Modeling Language (RAML), which makes it easy to manage the whole API lifecycle from design to sharing. Enterprises saw the benefits of RAML’s API-spec-centric approach, and the industry has since incorporated it broadly.

MuleSoft recently joined the OpenAPI Initiative of the Linux Foundation, and now MuleSoft’s Anypoint Platform explicitly supports OAS (OpenAPI Specification, formerly Swagger) for describing APIs. MuleSoft Design Center supports importing an OAS 2.0 specification in JSON or ZIP format from the file system. We can also import an OAS 2.0 specification from the internet.

In this article, we will demonstrate how we can use OAS 2.0 API Specification in MuleSoft for API design and implementations.

Let’s get started. First, we will use SwaggerHub (https://app.swaggerhub.com) to create our API Specification using OAS 2.0.

As shown in the above screen resource, “/persons/{personId}” has been created on the HTTP GET method to get the details of a particular person. There are two parameters has been defined in the spec, “personId” as URI parameter and "clientid" as a header parameter. As part of the service response, we have created schemas for both success and error scenarios.

In the SwaggerHub UI, we will validate the specification and do the mock testing on the API specification. Once the API specification gets validated and looks good, let’s download the API specification from SwaggerHub, as shown in the above screen. 

Now, we will use the downloaded OAS 2.0 API specification in MuleSoft Design Center.

Let's create a new API Specification in Mule Design Center and import the API specification, as shown in the below screen. Here we can import the OAS specification as a file or zip or from a URL.

Let’s browse the zip file which we downloaded from SwaggerHub and finish the import. The converted OAS code appears in RAML in the editor panel, as shown in below screen.

Please beware, there are some limitations and issues in this OAS to RAML conversion due to different annotations and formats of these two languages. This will be resolved going forward, but from our side, let’s mock test the API specifications to make sure the conversion happens well for the specification we just created.

Now we have a well-designed and tested RAML API specification which we can use to create Mule projects.

Let’s share our knowledge to expand our MuleSoft community.

Thank you!