Menu
Live Demo Download

Creating Mock API with Apinizer

Mock API allows simulating the behavior of a real API. Thus, when we make an HTTP call to the endpoint we created without any software development, a predetermined response is returned.

Why do we need it?

We are now developing API-based web/mobile applications or integrating different systems into our applications via API/Web services. Now, let’s take a look at the most common Mock API use case. The API development task is generally performed by the backend team, and the frontend/mobile team develops its components over it. In such a scenario, two teams can be expected to work in parallel. If the API design with information such as which endpoints the API will consist of, header, body, status code of the request and response in the endpoints is clear, the frontend/mobile team can continue to develop by imitating real data by mocking the API.

  • Thus, the dependency between teams is reduced.
  • Both the frontend/mobile team can develop faster, and the API development team can improve the API in the live environment based on the feedback of the frontend/mobile team. Therefore, the process can be managed more efficiently.
  • Functional testing can be started before the components are put into use.
  • Different error states can be generated and tested on request.
  • Paid APIs can be tested via mock API.
  • When production or sandbox environments are not accessible, instant responses can be sent in scenarios such as maintenance/update to the API.

So let’s do some mocking!

Creating Mock API

Apinizer allows you to easily generate Mock APIs via the default CRUD operations template or by importing API Documentation (Open API or Swagger).

A Mock API with CRUD operations is created with the ‘Blank’ type. Endpoints can be arranged according to the answers to be returned.

 

‘Import Spec’ option allows you to create Mock API by importing or uploading API Documentation.

Returning Different Response Based on Condition

While developing the Mock API, we talked about creating endpoints and editing the HTTP response to be sent to the client when the relevant endpoint is called. Another feature that should be mentioned while editing the answer is “condition“.

An important requirement of Mock API developers is to return different responses to requests coming to the same endpoint according to different situations For this, it is sufficient to create a condition instead of creating the same endpoint that meets every condition.

For example, when the endpoint ‘findByStatus?status={parameter}’ is called, another response body may be requested when the value of the parameter is ‘sold’, and another response when the value of the parameter is ‘available’.

Thanks to the conditions added to the response, Apinizer ensures that different responses are received based on the header, body, or parameter values of the request. There is no need to create a database, software development, or technical knowledge for this.

Viewing Mock API Specification Documents

Once the Mock API is created, the Swagger and Open API types of API description documents can be accessed on the fly in JSON and YAML formats.

Creating API Proxy from Mock API

Another advantage of Mock API created with Apinizer is that Mock API is presented to clients by creating API Proxy.

Advantages of creating API Proxy can be summarized as applying policy without writing code (CORS setting, Authentication Policies, Script Policy, Business Rule Policy, etc.), monitoring API traffic by logging HTTP request/response to incoming/sent message from a client

➳ Click here to get more information about Apinizer API Creator.

➳ Click here to try Mock API in Apinizer demo environment.