For the complete documentation index, see llms.txt. This page is also available as Markdown.
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:
