While the http protocol is rather basic in essence, it can be a pain to work with. reqres is here to soothe the pain somewhat by providing two powerful classes for handling all parts of request and response handling during a http exchange. This is not a web server, instead it focuses on making life easier for developers of web servers by extracting the complexity of cookies, headers, content negotiation, and the likes into neat little classes. reqres builds upon the rook specifications and is thus well suited for httpuv-based webservers.


reqres draws a lot of inspiration from express.js and the Request and Response classes is aiming for feature parity with those from express. The Request class provides automatic parsing of the query string along with parsing of the body based on the Content-Type header (with decompression if Content-Encoding is provided). Further, it provides content negotiation based on the Accept(-*) headers. The Response class allows you to set headers and cookies easily, assign arbitrary data for later use, and automatically format the body based on content negotiation with the Request object that it is responding to (again, it will compress automatically if the Accept-Encoding header allows it). If any part of the content negotiation fails the correct response status code will be set, making the response ready to send.

reqres comes with a range of parsers and formatters making it work out of the box with json, xml, html, csv, tab, multipart, and www-form-urlencoded payloads. It is easy to either modify these or provide your own parsers and formatters if needed - reqres will take care of the content negotiation and simply call your custom parser/formatter if chosen.


reqrescan be installed from CRAN with install.packages('reqres') or the development version can be installed from github:


Below is a quick demo of some of the features in reqres. It uses the fake_request() in fiery to mock a rook request so it can be used without setting up a webserver:


A lot of information is already available, such as the query and other parts of the url, but the body is not filled in automatically.

The body can easily be parsed though, as long as a parser exists for the provided content type.

Instead of inspecting it manually you can simply provide a range of parsers and let the object choose the correct one itself

In the case that none of the provided parsers fits the content type, the response will automatically get updated with the correct error code

To facilitate all this reqres comes with a mapping of standard mime types to the provided parsers. This can simply be supplied to the parse method


While the request is mainly intended to be read from, the response should be written to. The Response class contains a slew of methods to easily set headers, cookies, etc.

Furthermore, it contains its own data store where arbitrary information can be stored so as to pass it between middleware etc. This data will never be part of the actual response.

Files can be attached and marked for download, setting the relevant headers automatically

Often we need to provide a payload in the form of a body. This can be any type of R object until the response is handed off to the server, where it should be either a string or a raw vector.

Based on the Accept header in the request it can be formatted correctly thus making it ready to send back to the client. As this request contains an Accept-Encoding header it will be compressed as well.

The content negotiation understands wildcards as well

A default formatter mapping exists in parallel to default_parsers for the Request$format() method.

It is easy to define your own formatters and add them along the defaults

Code of Conduct

Please note that the ‘reqres’ project is released with a Contributor Code of Conduct. By contributing to this project, you agree to abide by its terms.