Responses
A spec-based mock answers from the operation a request matches. Given the same document and the same request, it gives the same answer, so tests stay stable. Generated bodies use the same sample generator as your published API document.
How a response is chosen
Status. The lowest declared 2xx. If there is none, the first declared status, or default as 200.
Media type. The best match for the Accept header, honoring */*, type/* and q values. With no Accept header, application/json if declared, otherwise the first one. If nothing matches, the answer is 406. A response that declares no content has an empty body.
Body, in this order:
- The media type’s
example - The first entry of the media type’s
examples - The schema’s
example, or the first of itsexamples - A body generated from the schema
Generated bodies are deterministic. They honor format, enum, default, readOnly, writeOnly and allOf, and take the first choice of oneOf and anyOf.
Headers. Response headers the document declares, with their example or a sampled value, plus Content-Type and x-apigit-mock-operation, which names the operation that answered.
Control a response with the Prefer header
| Header | Effect |
|---|---|
Prefer: code=404 | Answer with this status. It must be declared by the operation, exactly or as a range such as 4XX. |
Prefer: example=sold | Answer with this named example from the media type’s examples |
Prefer: dynamic=true | Generate random, realistic values instead of the stable sample. A declared example still wins. |
Prefer: validate=false | Skip every check on this request. See Request validation. |
Prefer: validate=body | Run only the named checks: parameters, body, credentials |
Combine preferences with commas, for example Prefer: code=200, example=sold.
The code, example and dynamic preferences use the same conventions as Prism, so tests written for Prism carry over.
# exercise your client's error handling
curl -i https://petstore-sandbox.mockserver.apigit.com/api/v3/pet/1 \
-H 'api_key: anything' -H 'Prefer: code=404'HTTP/2 404
content-type: application/jsonAsking for something the operation does not declare is an error, not a silent fallback:
{
"type": "https://apigit.com/mock/problems/unknown-status",
"title": "The operation does not declare this status",
"status": 422,
"detail": "The operation does not declare status 418. Declared: 200, 400, 404.",
"declared": ["200", "400", "404"]
}Matching requests
- Literal path segments win over parameters, so
/pets/minewins over/pets/{id}. - A path with no operation answers
404. A path that exists without that method answers405with anAllowheader. HEADwithout its own operation is answered by theGEToperation, without a body.- Browser cross-origin requests work: preflight
OPTIONSrequests are answered, and responses carryAccess-Control-Allow-Origin.
Limits on generated bodies
| Limit | Value |
|---|---|
| Items in a generated array | 20 |
| Characters in a generated string | 1,024 |
| Nodes in a generated response | 10,000 |
| Generated body size | 1 MiB |
| Time to answer one request | 2 seconds |
Larger minItems and minLength values are reduced to fit. A response that still cannot be generated answers 500 unsupported-mock. These limits apply to generated bodies, not to examples you wrote.
Need a response that depends on earlier requests? A spec-based mock keeps no state between requests. Use a code-based mock for that.