Mocking

The goal of mocking HTTP requests is to simulate the behavior of an actual API. This can involve:

• Returning hard-coded responses

• Returning recorded reponses

• Generating responses

Stoobly's mocking relies on returning hard-coded or recorded responses.

How are requests matched?

Scenario

If a scenario is specified, then only requests within that scenario will be considered.

If no scenario is specified, then any request will be considered.

If there are multiple matches in a scenario, then each response will be returned in the order in which they were recorded.

Components

The following request components are matched in a case-sensitive manner:

• HTTP Method

• Path

• Body

• Query Parameters

• Headers

• Body Parameters

HTTP Method

Which HTTP method(s)/verb(s) the rule applies to such as GET, POST, DELETE, etc.

Path

e.g. /users

Body

If provided, a strict matching of the body is required.

The following requests components can be marked as optional in the UI. An optional request component will not be used for matching purposes when mocking a request. To learn more, visit here.

Query Parameters

e.g. ?organization=1

The order of the query parameters are sorted in alphabetical order before comparison.

Headers

e.g. Content-Type: application/json

The order of the headers are sorted in alphabetical order before comparison.

Body Parameters

Body parameters are dependent on the Content-Type header in the request. If the body is a parseable format, body parameters will be parsed out, sorted in alphabetical order, and compared. The following parseable formats are currently supported:

• application/json

• application/x-www-form-urlencoded

When are requests matched?

Mocking a HTTP request with Stoobly