WIP: inets: Add map-based request interface to httpc

[jchristgit]

This is a very rough first draft towards potentially adding a new map-based request interface to httpc, the reason being that the existing request interface is a bit clunky to use & this might make it more straightforward. Most of the changes are adding types to many of the arguments to the requests.

This somewhat comes out of this thread on the Erlang Forums: https://erlangforums.com/t/httpc-httpd-improvements/2622

Example usage:

> {ok, #{status := Status} = Response} = httpc:request(#{method => get, uri => "https://erlang.org"}).

If there is interest, I'm happy to refine this further. Some open questions:

• Should we perhaps create different request types for synchronous and asynchronous requests to allow clearly distinguishing these in the specs? Since they differ quite a bit, maybe we should add async as a top-level field in the request map.
• Should we perhaps create different request types for requests without and requests with a body to allow clearly distinguishing them in the specs? Alternatively, we could incorporate the content type into the request body field, which might be simpler.

[github-actions]

CT Test Results

No tests were run for this PR. This is either because the build failed, or the PR is based on a branch without GH actions tests configured.

Results for commit 12e9c89

To speed up review, make sure that you have read Contributing to Erlang/OTP and that all checks pass.

See the TESTING and DEVELOPMENT HowTo guides for details about how to run test locally.

Artifacts

• Complete CT logs (Download Logs)
• No HTML docs found
• No Windows Installer found

// Erlang/OTP Github Action Bot

[tsloughter]

Nice. I too started on a map interface. I did so first as a POC in a separate project to try things out before proposing them to OTP, https://github.com/tsloughter/reqerl

I never liked the 3-tuple return value of httpc so went with a single map. It is named reqerl here but figured if people liked some of the suggestions I'd propose it as either being httpc in OTP or httpc2 (hm, guess that'd be confusing if it didn't support http2...):

> reqerl:get("https://reqbin.org/json")
#{status => 200, headers => #{...}, body => [#{<<"x">> => 1,<<"y">> => 2},#{<<"x">> => 3,<<"y">> => 4}]}

I got stalled when I was debating back and forth about how I wanted to do middleware -- something I consider important to even a builtin http client because of its importance for observability. But at the same time I agree with people like @josevalim who who think it'd be great to have a new "gen_http" in OTP as a low level interface to HTTP.

I plan to pick back up reqerl again in the near future.

[tsloughter]

Oh, blergh, I just realized you had #{status := Status} = Response :), I'm so used to the current httpc I read that as #{status := Status}, Response.

My bad!

[jchristgit]

Nice. I too started on a map interface. I did so first as a POC in a separate project to try things out before proposing them to OTP, https://github.com/tsloughter/reqerl

Thank you for sharing! I'm also 50/50 with the thoughts of supporting e.g. middleware in OTP's HTTP client as opposed to keeping it low level. I really like the reqerl_interceptor idea to e.g. decode responses automatically!

My goal here is mainly just to make the main request / response interface a bit cleaner to use. That way I can kind of skip any deeper design discussions 😁. Maybe later, the inner guts could be changed so this would just call out to what gen_http would be, so it would continue working for the "sending simple requests" usecase as is, but other libraries could build on top of it.

Anyways, that's very far future thinking, right now my goal is just to improve the docs and "ergonomics" here a bit 😄