The low-level API and the request struct.

Req is composed of three main pieces:

• Req - the high-level API

• Req.Request - the low-level API and the request struct (you're here!)

• Req.Steps - the collection of built-in steps

The low-level API and the request struct is the foundation of Req's extensibility. Virtually all of the functionality is broken down into individual pieces - steps. Req works by running the request struct through these steps. You can easily reuse or rearrange built-in steps or write new ones.

To make using custom steps by others even easier, they can be packaged up into plugins. See "Writing Plugins" section for more information.

The Low-level API

Most Req users would use it like this:

Req.get!("https://api.github.com/repos/wojtekmach/req").body["description"]
#=> "Req is a batteries-included HTTP client for Elixir."

Here is the equivalent using the low-level API:

url = "https://api.github.com/repos/wojtekmach/req"

req =
  Req.Request.new(method: :get, url: url)
  |> Req.Request.append_request_steps(
    put_user_agent: &Req.Steps.put_user_agent/1,
    # ...
  )
  |> Req.Request.append_response_steps(
    # ...
    decompress_body: &Req.Steps.decompress_body/1,
    decode_body: &Req.Steps.decode_body/1,
    # ...
  )
  |> Req.Request.append_error_steps(
    retry: &Req.Steps.retry/1,
    # ...
  )

{req, resp} = Req.Request.run_request(req)
resp.body["description"]
#=> "Req is a batteries-included HTTP client for Elixir."

By putting the request pipeline yourself you have precise control of exactly what is running and in what order.

The Request Struct

Public fields are:

• :method - the HTTP request method.

• :url - the HTTP request URL.

• :headers - the HTTP request headers. The header names must be downcased.

• :body - the HTTP request body.

  Can be one of:

  • iodata - eagerly send request body

  • enumerable - stream request body

• :into - where to send the response body. It can be one of:

  • nil - (default) read the whole response body and store it in the response.body field.

  • fun - stream response body using a function. The first argument is a {:data, data} tuple containing the chunk of the response body. The second argument is a {request, response} tuple. For example:

    into: fn {:data, data}, {req, resp} ->
      IO.puts(data)
      {:cont, {req, resp}}
    end

  • collectable - stream response body into a Collectable.t/0.

• :options - the options to be used by steps. The exact representation of options is private. Calling request.options[key], put_in(request.options[key], value), and update_in(request.options[key], fun) is allowed. get_option/3 and delete_option/2 are also available for additional ways to manipulate the internal representation.

• :halted - whether the request pipeline is halted. See halt/1

• :adapter - a request step that makes the actual HTTP request. Defaults to Req.Steps.run_finch/1. See "Adapter" section below for more information.

• :request_steps - the list of request steps

• :response_steps - the list of response steps

• :error_steps - the list of error steps

• :private - a map reserved for libraries and frameworks to use. The keys must be atoms. Prefix the keys with the name of your project to avoid any future conflicts. The req_ prefix is reserved for Req.

Steps

Req has three types of steps: request, response, and error.

Request steps are used to refine the data that will be sent to the server.

After making the actual HTTP request, we'll either get a HTTP response or an error. The request, along with the response or error, will go through response or error steps, respectively.

Nothing is actually executed until we run the pipeline with Req.Request.run_request/1.

Request steps

A request step is a function that accepts a request and returns one of the following:

• A request

• A {request, response_or_error} tuple. In that case no further request steps are executed and the return value goes through response or error steps

Examples:

def put_default_headers(request) do
  update_in(request.headers, &[{"user-agent", "req"} | &1])
end

def read_from_cache(request) do
  case ResponseCache.fetch(request) do
    {:ok, response} -> {request, response}
    :error -> request
  end
end

Response and error steps

A response step is a function that accepts a {request, response} tuple and returns one of the following:

• A {request, response} tuple

• A {request, exception} tuple. In that case, no further response steps are executed but the exception goes through error steps

Similarly, an error step is a function that accepts a {request, exception} tuple and returns one of the following:

• A {request, exception} tuple

• A {request, response} tuple. In that case, no further error steps are executed but the response goes through response steps

Examples:

def decode({request, response}) do
  case Req.Response.get_header(response, "content-type") do
    ["application/json" <> _] ->
      {request, update_in(response.body, &Jason.decode!/1)}

    [] ->
      {request, response}
  end
end

def log_error({request, exception}) do
  Logger.error(["#{request.method} #{request.uri}: ", Exception.message(exception)])
  {request, exception}
end

Halting

Any step can call halt/1 to halt the pipeline. This will prevent any further steps from being invoked.

Examples:

def circuit_breaker(request) do
  if CircuitBreaker.open?() do
    {Req.Request.halt(request), RuntimeError.exception("circuit breaker is open")}
  else
    request
  end
end

Writing Plugins

Custom steps can be packaged into plugins so that they are even easier to use by others.

Here's an example plugin:

defmodule PrintHeaders do
  @doc """
  Prints request and response headers.

  ## Request Options

    * `:print_headers` - if `true`, prints the headers. Defaults to `false`.
  """
  def attach(%Req.Request{} = request, options \\ []) do
    request
    |> Req.Request.register_options([:print_headers])
    |> Req.Request.merge_options(options)
    |> Req.Request.append_request_steps(print_headers: &print_request_headers/1)
    |> Req.Request.prepend_response_steps(print_headers: &print_response_headers/1)
  end

  defp print_request_headers(request) do
    if request.options[:print_headers] do
      print_headers("> ", request.headers)
    end

    request
  end

  defp print_response_headers({request, response}) do
    if request.options[:print_headers] do
      print_headers("< ", response.headers)
    end

    {request, response}
  end

  defp print_headers(prefix, headers) do
    for {name, value} <- headers do
      IO.puts([prefix, name, ": ", value])
    end
  end
end

And here is how we can use it:

req = Req.new() |> PrintHeaders.attach()

Req.get!(req, url: "https://httpbin.org/json").status
200

Req.get!(req, url: "https://httpbin.org/json", print_headers: true).status
# Outputs:
# > accept-encoding: br, gzip
# > user-agent: req/0.3.0-dev
# < date: Wed, 11 May 2022 11:10:47 GMT
# < content-type: application/json
# ...
200

req = Req.new() |> PrintHeaders.attach(print_headers: true)
Req.get!(req, url: "https://httpbin.org/json").status
# Outputs:
# > accept-encoding: br, gzip
# ...
200

As you can see a plugin is simply a module. While this is not enforced, the plugin should follow these conventions:

• It should export an attach/1 function that takes and returns the request struct

• The attach functions mostly just adds steps and it is the steps that do the actual work

• A user should be able to attach your plugin alongside other plugins. For this reason, plugin functionality should usually only happen on a specific "trigger": on a specific option, on a specific URL scheme or host, etc. This is especially important for plugins that perform authentication; you don't want to accidentally expose a token from service A when a user makes request to service B.

• If your plugin supports custom options, register them with register_options/2

• Sometimes it is useful to pass options when attaching the plugin. For that, export an attach/2 function and call merge_options/2. Remember to first register options before merging!

Adapter

As noted in the "Request steps" section, a request step besides returning the request, might also return {request, response} or {request, exception}, thus invoking either response or error steps next. This is exactly how Req makes the underlying HTTP call, by invoking a request step that follows this contract.

The default adapter is using Finch via the Req.Steps.run_finch/1 step.

Here is a mock adapter that always returns a successful response:

adapter = fn request ->
  response = %Req.Response{status: 200, body: "it works!"}
  {request, response}
end

Req.request!(url: "http://example", adapter: adapter).body
#=> "it works!"

Here is another one that uses the Req.Response.json/2 function to conveniently return a JSON response:

adapter = fn request ->
  response = Req.Response.json(%{hello: 42})
  {request, response}
end

resp = Req.request!(url: "http://example", adapter: adapter)
resp.headers
#=> [{"content-type", "application/json"}]
resp.body
#=> %{"hello" => 42}

And here is a naive Hackney-based adapter:

hackney = fn request ->
  case :hackney.request(
         request.method,
         URI.to_string(request.url),
         request.headers,
         request.body,
         [:with_body]
       ) do
    {:ok, status, headers, body} ->
      headers = for {name, value} <- headers, do: {String.downcase(name, :ascii), value}
      response = %Req.Response{status: status, headers: headers, body: body}
      {request, response}

    {:error, reason} ->
      {request, RuntimeError.exception(inspect(reason))}
  end
end

Req.get!("https://api.github.com/repos/wojtekmach/req", adapter: hackney).body["description"]
#=> "Req is a batteries-included HTTP client for Elixir."