MuleSoft API lifecycle – Use Case

As we already walked through the MuleSoft API lifecycle theory so now it’s time to start with the actual MuleSoft API lifecycle – Use Case.

Requirement – Mobile team come with a requirement that they need an interface which can accept the order placed from the mobile application and can also provide the user’s order details in case they need at any time.

NFR (Non Functional Requirement) – Mobile team want to use basic authorization for calling the service and the response should be in 5 sec max.

MuleSoft team/consultant looks into the requirement and will start with the API specification. Here team needs to provide interface for order management. API will provide user’s order information and accept the user’s placed order.

MuleSoft API lifecycle – Use Case

Design

API Designer – We start with we create order-mgmt-api project in design center.

Click on create new and fill in the details

First we create the types.raml which will hold the type details which we are going to use in api RAML

Second we create the api RAML which will hold the API specification

Specification will hold order resource which will have GET and POST method

GET will take the user id as query parameter and provide user order details

POST will take the user id and item details which need to create in order management system

Both methods will be secured through basic authentication

Download the Sample order-mgmt-api

Prototype

Mock Service – Once we are done with the API specification then we enable the Mocking Service button

API base URI will be generated which can be tested through and API testing client like POSTMAN or SOAPUI

Select GET method and click on try it

Provide dummy userid and basic authorization details

Then we can see the 200 response as well

Validate

API Console – This console is generated by default by the API Kit router configuration. Once application is deployed to mule runtime then this console is available. Will show this when we generate source code for the application.

Till now is a recursive process where we keep on validating the RAML design/specifications with clients/vendors and based on the feedback either we again follow the process (RAML design -> Mocking Service -> Validate) or move ahead with development

When we received the positive feedback from clients/vendor we move to Develop and Testing phase.

Develop –Anypoint Studio can directly download the API Specification (RAML) from design center and create a base mule application

Select File -> New -> Mule Project

Select “From Design Center or Local files”

Select the order-mgmt-api from the selection box and click OK

Provide the project name and click Finish

This will create a mule application with basic skeleton

With both GET and POST method flows, based on the RAML specification

And API console code

Testing – when we are done with the development and add the required logic in our mule application. We have to write the MUNIT to make it sure that future changes will not break the existing logics.

We can select the flow and create the MUNIT for the flow

This will create the MUNIT for the flow which we can update as per our assertion logic

Download sample mule application project – order-mgmt-api

Deploy

Runtime Manager – Once we are done with the development and MUNIT, then we can deploy our code to mule runtime. We will deploy our code to Cloudhub.

Login to Anypoint Platform and go to Mule Runtime Manager

First export the project jar which can be deployed to Cloudhub

Select the project -> export

Click Next

Please select “include project modules and dependencies” as we have to deploy the same project on Cloudhub

A Jar will be exported which can be deployed on Cloudhub

On Anypoint Platform – Select Runtime Manager

Click on Deploy application

Provide the appropriate name and deploy the application

Once deployed we can test the API

To test the API we need to create the URL which needs to be called

Click on dashboard

Select the domain name

http://order-mgmt-api.us-e2.cloudhub.io

HTTP will be as per the configured Listener in mule application – click on edit in Anypoint Studio

We can see here the default listener is HTTP

Remaining information we can get from path and RAML

http://order-mgmt-api.us-e2.cloudhub.io/api + RAML resource

So effective URL is

http://order-mgmt-api.us-e2.cloudhub.io/api/orders

Add the query parameters

http://order-mgmt-api.us-e2.cloudhub.io/api/orders?userId=1234

When we test the API it will show the result

But we are still missing something, it still not secure as we are not providing basic authorization details. To add security, MuleSoft come with OOTB functionality called API Manager to easily secure the APIs.

Operate

API Manager – To apply policy in API Manager we have to add Auto Discovery details, please go through Auto Discovery tutorial to know the same.

Assuming now you know how to add Auto Discovery, we start the API Manager configuration by pushing the RAML from Design Center to Exchange

Click on Publish and then Publish to Exchange

In Exchange now we can see the Asset

Now we move to API Manager and create the required configuration and add the Auto Discovery details

Once application deployed using Auto Discovery details, API Manager configuration will come in Active state from Unregistered state

Add the Client id enforcement policy

Now if we hit the same URL – we can see the API is asking for basic authorization

if not provided we will get below error

Will raise the client authentication request from Exchange

After providing the authorization details we can call the API successfully

Anypoint Analytics – This is replaced with Anypoint Monitoring and Visualizer in current Anypoint Platform. For the Developer account we don’t have access to enable and show it here.

Publish

API Exchange – as a part of API Manager Configuration we add the Design Center project to Exchange. This will help the organization and connected partners to discover existing APIs as per their needs.

We also update the Exchange asset to include more meaning full information which can talk about the asset

With this we end the API Lifecycle

API Lifecycle will not stop here and again go into next lifecycle based on the feedback.

E.g. Existing Order management APIs are not capable enough to handle customize items, so based on this new requirement a new set of API version e.g. 1.0.1 is created.