davidantaramian / httpipe Goto Github PK

I'm envisioning a system similar to Plug's parsers where a user can specify what module to use to parse what types of content. HTTPipe would then decode incoming requests based on the content-type header into the decoded_body key on the response.

I'm not sure if this makes sense in the context of this library, but if someone is interested, I'd like to know how you see it being used.

Currently URLs are stored as strings which isn't helpful in many situations beyond sending the request. By storing the URL in its composite pieces, it makes it easier to work with over time.

It would be nice if there was a function like this:

HTTPipe.Conn.new(%HTTPipe.Request{})

Example of how I am doing it now:

    req = %HTTPipe.Request{
      method: :post,
      url: "/cloud/project/#{service_name}/user/#{user_id}/regeneratePassword"
    }
    Map.put(HTTPipe.Conn.new(), :request, req)

Would be nice if I could

%HTTPipe.Request{
      method: :post,
      url: "/cloud/project/#{service_name}/user/#{user_id}/regeneratePassword"
    }
|> HTTPipe.Conn.new()

• In order to add custom elements in a library which uses HTTPipe, I think the field private would be desirable.
• At the moment I'm just adding my custom fields to the HTTPipe.Conn.t which is not ideal.
  Plug has a private field.

https://github.com/elixir-lang/plug/blob/v1.3.0/lib/plug/conn.ex#L163

@DavidAntaramian, your thoughts on this?

Is cookie support an interesting feature for anyone? What would the function calls look like to you?

Should it be possible to register functions that should be called before a connection is executed in order to modify the request in some fashion?

The specification would look something like this, allowing for both anonymous functions and named functions:

@type before_execute_fun :: (HTTPipe.Request.t -> HTTPipe.Request.t)
@spec register_before_execute(HTTPipe.Conn.t, before_execute_fun) :: Conn.t
@spec register_before_execute(HTTPipe.Conn.t, module, atom) :: Conn.t

In the second case, the atom would refer to a single-arity function in the given module with a spec of (HTTPipe.Request.t) :: HTTPipe.Request.t.

One of my biggest concerns with the library currently is that pooling connections is dependent on the individual adapter. I'm open to ideas about a more canonical way to implement pooling at the library level rather than at the adapter level.