Mock Routing

Edit online

If you have a native API that is hosted at two or more endpoints, you can use the Content-based routing protocol to route specific types of messages to specific endpoints. You can route messages to different endpoints based on specific values that appear in the request message.

You might use this capability, for example, to determine which operation the consuming application has requested, and route requests for complex operations to an endpoint on a fast machine. For example, if your entry protocol is HTTP or HTTPS, you can select the Content-based routing. The requests are routed according to the content-based routing rules you create. You may specify how to authenticate requests.

In API Studio, the kind Route identifies this policy.

Example of a Mock Routing policy:

kind: Route
apiVersion: api.webmethods.io/beta
metadata:
  name: api-mock-route
  description:
  version: 1.0
  namespace: sample
  tags:
    - mock
spec:
  mock-endpoint:
    enabled: true
    $ref: sample:api_mock:1.0
---
kind: MockEndpoint 
apiVersion: api.webmethods.io/beta
metadata:
  name: api_mock
  description: This is the mocking file for Pet store API
  version: 1.0
  namespace: sample
  tags:
    - swagger
    - petstore
    - sample
    - mock
spec:
 config:
    - condition: ($request.path equals v2/pet and $request.method equals GET and $request.query.<key1> equals 'test')
      response:
        $ref: sample:api_response:1.0
    - condition: ($request.path equals v2/pet and $request.method equals POST and $request.query.<key1> equals 'test' and $request.body.<val>)
      response:
        $ref: sample:api_response:1.0
    - condition: default
      response:
        $ref: sample:api_response:1.0
---
kind: MockResponse
apiVersion: api.webmethods.io/beta
metadata:
  name: api_response
  description: This is the mocking file for Pet store API
  version: 1.0
  namespace: sample
  tags:
    - swagger
    - petstore
    - sample
    - mock
spec:
  code: 201
  headers:
    - key: auth
      value: <token>
  data:
    - contentType: application/json
      content: {empid: 1}
    - contentType: application/xml
      content: <test></test>

To invoke the Mock Routing policy, you can specify:

Type	Description
kind	`Route`. Defines the type of policy that is being configured.
apiVersion	Denotes the version of the API in use.
metadata	Denotes the metadata or details of the asset type. It covers this metadata: `name`. Name of the policy. `version`. Version of the policy. `namespace`. Namespace of the policy. `tags`. The tags associated with the policy. Use the following tags to tag the Mock Routing policy: `mock`
spec	You can configure the following policy specifications: `mock-endpoint`. Specifies the URI of the mock API endpoint to route the request to. This endpoint is provided as $ref value in the format `$ref: <endpoint name>: version`

To configure the mock_endpoint, you can specify:

Type	Description
kind	`MockEndpoint`. Defines the type of asset that is being configured.
`apiVersion`	Denotes the version of the API in use.
`metadata`	Denotes the metadata or details of the asset type. It covers this metadata: `name`. Name of the asset. `version`. Version of the asset. `namespace`. Namespace of the policy. `tags`. The tags associated with the policy. Use the following tags to tag the `MockEndpoint` policy: `swagger` `petstore` `sample` `mock`
`spec`	This denotes various asset properties that you can specify for the endpoint. `config`. Define one or more conditions and the mock responses to return when those conditions are met. These are the endpoint configurations to be specified: `condition`. Specify the criteria to match incoming requests, such as request path, method, query parameters, or body content. `response`. Provide a reference to a predefined mock response that should be returned when the condition is met. This response is provided as $ref value in the format `$ref: <response name>: version`

To configure the MockResponse, you can specify:

Type	Description
kind	`MockResponse`. Defines the type of asset that is being configured.
`apiVersion`	Denotes the version of the API in use.
`metadata`	Denotes the metadata or details of the asset type. It covers this metadata: `name`. Name of the asset. `version`. Version of the asset. `namespace`. Namespace of the policy. `tags`. The tags associated with the policy. Use the following tags to tag the `MockResponse` policy: `swagger` `petstore` `sample` `mock`
`spec`	This denotes various asset properties that you can configure for the response. These are the mock response specifications that can be configured: `code`. Specify the HTTP status code to return in the mock response. `headers`. Define custom headers to include in the mock response. Configure the `key` and `value`. `data`. Provide one or more response bodies in different content types. Specify the following: `contentType`. Specify the media type of the response content, such as `application/json` or `application/xml`. `content`. Define the actual response body to return for the given content type.