Using local interceptors
HTTP interceptors allow you to handle requests and return custom responses. Their primary use is to mock HTTP requests in development or testing environments, especially when the backend is unavailable or when you want to have more control over the responses.
Using remote interceptors
HTTP interceptors allow you to handle requests and return custom responses. Their primary use is to mock HTTP requests in development or testing environments, especially when the backend is unavailable or when you want to have more control over the responses.
Using headers
HTTP headers are key-value pairs that contain additional information about a request or a response. They are commonly used to pass metadata, such as a content type, authentication tokens, or caching directives.
Using search params (query)
URL search parameters, also known as query parameters, are a way to provide additional information to a request. They are encoded in the query string of a URL in key-value pairs. Search params are typically used in GET requests to filter, sort, or paginate data.
Using path params
Path parameters are a way to include dynamic values in the URL path of a request. They are typically used to identify a resource being accessed or modified. For example, in the URL /users/userId represents a path parameter that can be replaced with a specific user identifier when making a request.
Using bodies
Bodies are used to send data in a request and receive data in a response. Request bodies are commonly used to include a payload of data that the server will process, whereas response bodies may contain the result returned by the server. A body can contain various types of data, such as JSON, XML, and binary data such as images and files.
Declarative assertions
@zimic/interceptor provides a way to declaratively check if your application is making the expected HTTP requests, using restriction and number of request assertions. They make it possible to have robust tests with declarative conditions verifying your application, without having to write complex logic to manually check all requests.
Declarative delays
HTTP interceptors are very efficient and can respond requests within milliseconds. This is great to keep your development and test environments fast, but sometimes you may want to simulate network latency, reproduce server processing time, check loading states in your application, or test how it behaves under slow conditions.
Unhandled requests
When a request is not matched by any interceptor, it is considered unhandled and will be rejected and logged to the console by default.
Testing
@zimic/interceptor is designed with testing in mind and provides utilities to give you confidence in your tests. Using declarative assertions, you can write your expectations in a readable way that makes it clear how many requests the application should make, what parameters they should have, and what responses they will receive. If you need more specific assertions, the requests processed by the interceptor are available in handler.requests.
Typegen
@zimic/interceptor uses @zimic/http, which can infer types from OpenAPI documentation and generate ready-to-use schemas to type your @zimic/interceptor interceptors.