Build a Mock API

A Mock API is useful to get feedback from API consumers (e.g developers) on the API design. It may also be useful for testing when there is no test API available.

Below is an example on how to create a Mock API returning {"message": "Hello World!"} when calling GET /examples/hello-world.

To be able to modify this example and create your own mock, you need an API sandbox. Create an API sandbox here.

To add new Mock API endpoints you just change method and path.

To change what is returned from the Mock API endpoint. Change the value of the /response field in the snippet below (e.g change the body to {"hello": "to the world!"}).

Copy the snippet below, replace {{SANDBOX_AUTH}} and {{SANDBOX_BASE_PATH}} and execute the command:

curl --location --request POST 'https://api.zuunr.com/endpoint-configs' \
--header 'Authorization: {{SANDBOX_AUTH}}' \
--header 'Content-Type: application/json' \
--data-raw '{
  "method": "get",
  "path": "{{SANDBOX_BASE_PATH}}/hello-world",
  "processors": {
    "onRequest": {
      "Translator": {
        "transformations": [
          {
            "/response": {
              "body": {
                "message": "Hello World!"
              },
              "status": 200
            }
          },
          {
            "/next": "sendResponse"
          }
        ]
      }
    }
  }
}'

Test your API mock endpoint by doing a GET call to: https://api.zuunr.com{{SANDBOX_BASE_PATH}}/hello-world

Detailed explanation

path	URL path of the API endpoint
method	HTTP method (e.g get, post, patch, delete)
processors	Execution steps performed by the API to fulfill the request.

Processors

Processors are the execution steps to be performed by the API to handle the request. A processor consists of exactly one component (e.g Translator) and some configuration for that component. Processors may do validations, calculations and transformations to create a response, integrate with databases or call other APIs with over HTTP.

Processor model

When a processor is executed it updates the processor model. A processor may update the model different ways but is required to at least specify the name of the next processor to be executed in the model at field /next.

When the onRequest processor is started the HTTP request is present in the model as /request in JSON format. In the example, the model is:

{
  "request": {
    "method": "get",
    "path": "/examples/hello-world"
  }
}

Request headers are omitted for readability in the example above.

The sendResponse processor expects the model to be updated with the HTTP response as /response in JSON format. When the /sendResponse processor is started in the example, the model is:

{
  "request": {
    "method": "get",
    "path": "/examples/hello-world"
  },
  "response": {
    "status": 200,
    "body": {
      "message": "Hello World!"
    }
  }
}

Request headers and Response headers are omitted for readability in the example above.

Predefined processor names

onRequest

The first processor that will be executed when the API recieves the request. This processor is required and MUST be defined in /endpoint-configs.

sendResponse

This is a built-in processor that sends a response to the API client. It can’t be defined in /endpoint-configs.

Translator component

The Translator component performs tranformations (modifications) to the model. In the example it is used to set /response to a static JSON object where status is 200 (OK) and body is {"message": "Hello World!"} and to set /next to sendResponse (which will execute the sendResponse processor after the Translator component has been executed).