Testing HTTP APIs with hurl
hurl is a command line tool for running HTTP requests. The clue is that the definitions of the HTTP requests are stored in plain text files, and that the CLI tool has some useful capabilities around working with HTTP requests and the corresponding responses. That allows for two main usages of the tool:
- Maintaining an internal library of API calls for manual testing during development. Think Postman, but backed by plain text files and a CLI tool.
- Building up a suite of end-to-end tests for automated testing, e.g. for continuous integration.
The following snippet demonstrates a .hurl file that would make a POST request to https://example.org/users, and attaches two HTTP headers plus a JSON payload to the request.
POST https://example.org/users
Accept: application/json
Authorization: Basic YWRtaW46cDRzc3cwcmQ
{
"name": "John Doe",
"is_active": true
}
That’s only a basic example, though. hurl let’s you capture and reuse parts of the responses (such as CSRF tokens), it can persist cookies, or can inject variables and header fields to parametrise your files. On top of that, you can also add assertions to your files and run hurl in test mode.
For me, the key advantages of hurl are two-fold:
- Storing all data in text files makes it easy to share and version-control them – you can put the
.hurlfiles directly into the source code repository of the respective web server. - Having a CLI tool facilitates extending and customising the work flows, to tailor them to your specific needs or preferences.