WireMock mocks HTTP-based services by matching requests to predefined responses. It lets a frontend call realistic API endpoints while the complete backend is still unavailable, making parallel UI development practical. section 6.5.2 section 6.9
Build a local WireMock service in a few steps:
- Create a Dockerfile from the WireMock image and add the service to docker-compose.yml. section 6.5.1
- Mount local __files and mappings directories as volumes, so mapping changes take effect without rebuilding the container. section 6.5.1
- Expose the service on port 8081 and inspect its administration endpoint at /__admin/. section 6.5.1
- Define mappings that match HTTP methods and URLs, then return status codes, headers, inline bodies, or files. section 6.5.2
- Refresh mappings through the administration API after changing files, allowing new responses to become available. section 6.5.2
Mocking ACH file data
A GET request to /api/v1/files can return ach_files_response.json from __files. A dashboard can then display uploaded ACH files without a live backend, while reusable response files keep mappings simpler. section 6.5.2 section 6.6
Matching dynamic paths
A mapping for /api/v1/files/{fileId}/batches uses urlPathTemplate and {{request.path.fileId}} to select a canned response for each file identifier, avoiding one mapping per identifier. section 6.6.1
Listing 6.30 WireMock templating example
{
"request": {
"method": "GET",
"urlPathTemplate": "/api/v1/files/{fileId}/batches" #1
},
"response": {
"status": 200,
"headers": {
"Content-Type": "application/json"
},
"bodyFileName": "ach_files_batches
➥{{request.path.fileId}}.json" #2
}
}
Inspect the compact mapping that combines a dynamic request path with a templated response filename. section 6.6.1
