zblanco / httpact Goto Github PK

Trial runs of the minimal dependency injection capabilities with HTTPact worked, but some common patterns emerged that we can abstract out further. The first is the to_request and from_response functions used to map between HTTPact structs and the API Resource structs.

To enforce and encapsulate these mapping functions I think the next step is to implement a protocol. In the gist HTTPact is based off of, he describes an Operation protocol that covers both to_request and from_response, however I'm thinking two separate protocols for Commands (to_request) and Entities (from_response) will support more flexibility and encourage this declarative approach. Naming may change, but Commands and Entities is pretty good.

This allows API Wrapper libraries be side-effect free by returning protocol enforced data structures which can be passed into HTTPact with a client/adapter. An API Wrapper library might also provide defaults and side-effect executing functions as a convenience, but the protocols make it easier to have this pure-impure separation by default.

We can take this further and simplify our Request structs by taking the :http_client out and instead making that a data-structure which includes the adapter and middleware type support. This will change the execute API to dispatch the data-structure protocol for conversions but also lets us include Authentication details in our client structure that our protocols can dispatch with.

Some kind of validation at the HTTPact.execute/1 boundary to ensure a valid request and client is provided before executing.

There are two main consumers for HTTPact:

• API Wrapper libraries
• HTTP Client implementations

As such these are the two points where some testing utilities would be helpful.

For API Wrapper libraries we'd likely want an easy way to build a valid HTTP Client that returns expected responses. This way the API Wrapper library can test their error handling and entity conversion properties.

For HTTP Client implementations we might need to go further and build a web server with similar controls for expected responses although with a focus on generic HTTP behavior. Likely a solution a long the lines of Bypass.