Introduction

Anypoint Exchange's Mocking Service is a powerful tool that provides real-time feedback during the API design process.
This article discusses the ways to use the Mocking Service, its drawbacks, and the proposal of the Mocking Service Proxy as a solution to these challenges.

Accessing the Mocking Service

Access to the Mocking Service from application essentially comes in two forms - public and private.

Public

The Mocking Service for assets published in Public Portals can be called without authentication.
However, the downside of this approach is the potential exposure of the API specification to external parties.
Therefore, this option needs careful consideration when security is critical.

Private

On the other hand, In the case of not publishing to Public Portals, access to the Mocking Service is limited to a specific set of users or groups.
However, this method requires implementing an additional program to obtain an access token from the Anypoint Platform.

Proposal of Mocking Service Proxy

As a solution to these issues, we propose the creation of a Mocking Service Proxy.
This Proxy encapsulates the process of obtaining the access token and allows usage with regular API authentication methods such as Client ID and Client Secret.

A major benefit of this approach is the ability to utilize the Mocking Service without exposing the API specifications and eliminating the manual process of obtaining the access token.
This allows developers to focus on make an application that call the API.

Mechanism of Mocking Service Proxy

The Mocking Service Proxy is based on the Endpoint with Proxy Mule application, which is generated through the API Manager.
The standard operation of the Endpoint with Proxy Mule application is to route the incoming API calls to the appropriate endpoints.

Before routing the API calls, the Mocking Service Proxy executes a process to obtain an access token from the Anypoint Platform.
This process encapsulates the client authentication method - using Connected App - and uses this information to request an access token from Anypoint Platform's authorization server.

Once the access token is obtained, it is attached to the API call as a token in the MS2-Authorization header.
Following this, the API call is routed to the appropriate endpoint, just as in the normal operation of the Endpoint with Proxy Mule application.

Now comes the decision-making process for routing. The Mocking Service Proxy determines which Mocking Service asset to call based on the first path segment. For instance, if the API request is /asset1/data, the Mocking Service for asset1 will be called.
This design allows efficient routing and ensures that the appropriate Mocking Service is called for each request.

Other approaches can also be considered for determining the Mocking Service to be used, such as determining based on HTTP header or setting up a Proxy for each asset. However, the first path segment-based approach provides a simple and effective solution that balances flexibility and complexity.

Benefit

One significant advantage of using the Mocking Service Proxy is its ability to bridge the gap between calling a Mocking Service and a implemented API endpoint.

For example, a implemented API endpoint require authentication using a Client ID and Client Secret.
On the other hand, a Exchange Mocking Service not require these authentication steps or has dedicated authentication steps.

The Mocking Service Proxy addresses this issue by encapsulating the authentication of Exchange Mocking Service process within its workflow. Requiring no additional steps from the developers.

In this way, the Mocking Service Proxy enables a seamless transition between the development and production environments. It allows developers to focus on the core aspects of their work - designing and implementing the API - without worrying about the intricacies of the authentication process and environmental discrepancies.

Sample Implementation

I have created a sample implementation that can be used as a reference.
You can find the sample implementation here. Please note that you may need to adjust the implementation to suit the specific needs and requirements of your project.

Conclusion

While the Mocking Service is an excellent tool for rapid feedback during the API design phase, its usage comes with certain challenges.
By leveraging the Mocking Service Proxy, these challenges can be addressed, making the development process more efficient.

The Mocking Service Proxy encapsulates the process of obtaining access tokens.
This allows developers to focus on application that call the API development.