OutSystems Mock API Paradigm (2/3)

In this multi-part article with a first part. Click here to read the first strategy of OutSystems Mock API Paradigm.

---

The many ways of approaching the creation of mock data in a project. Examples and the advantages of each approach: API mocking frameworks and tools

---

In OutSystems API-driven projects the development team is often blocked due to external API dependencies.

The purpose of this article is to help reduce the negative impact that the uncontrolled creation of mock data can have on projects and applications that are being developed, through 3 different approaches to building mock APIs in OutSystems.

• JSON in Server Action (Click here to see the first part)

• API mocking frameworks and tools

• REST/SOAP APIs

In this second part of the article, the API mocking frameworks and tools strategy will be addressed.

API mocking frameworks and tools

The second approach refers to API mocking frameworks and tools, which are mock API server or mock server API that imitates a real API server by providing realistic mock API responses to requests.

The following list has the most popular API integration and mocking frameworks and tools

(Source).

• WireMock – Java-based, simple API mock server.
• sMockin – Java-based API simulator
• Mockbin – API response generator with cloud-based UI.
• Mocky – simple API response mocking tool, based on Scala.
• Mockoon – API mocking tool, including nice UI, build with JavaScript and Electronjs
• Mountebank – is an advanced mocking framework. Allows you to create service virtualization and emulate APIs.
• SoapUI Mocks – the best known tool for working with SOA type services, also provided mocking capabilities.
• Mockapi.io – cloud-based API response mock service.
• Wilma – Service stub and transparent proxy, which allows to capture and analyze API requests.

Here, as an example, we will be using the Mocky.

1. The goal is to use the same Customer structure created in JSON in Server Actions.

The reasons that can lead us to create a mock through a mocking framework are:

• Possibility to easily set HTTP Status
• Possibility to define the Response Content-Type
• Possibility to set the Header

In other words, through the mocking framework, there are more possibilities, especially if you only want to retrieve the information. If you want to emulate more realistically what will come from the Webservices, start doing error handling, define Headers or specify Content-Type, you can define all these aspects in the mock API, as you can see in the image:

After parameterizing these values, it is enough to generate the HTTP Response and a mock URL is generated.

2. Create the Mock API.

NOTE: REST integration must be created at the Integration Service (IS) layer

The first step is to consume the mock service created from the mocking framework.

After creating the GET method, change the name of the method (e.g. GetConsumer) and structures, as needed.

IMPORTANT: Please note that the creation of mocks via mocking frameworks requires that any changes to the mock structures will require the creation of a new mock, but allows a more realistic simulation of the service that will be consumed.

3. Consume the mock API

The last step is to send the information to Core service layers and make the necessary abstractions.

This approach is simple and elegant and allows flexibility when mocking data. By doing this, you can cope with technical requirements. All that without the need of waiting for the original APIs.

NOTE: find in the Forge the Mock API Application with the examples.