Unit tests for the HyperTransport

[cmbrandenburg]

The HyperTransport is tested indirectly, via the integration tests. Consider writing unit tests for it to ensure all cases are covered.

[jgillich]

A bit OT, but: did you consider moving the transport into a separate crate, like a micro framework for API clients? The way it abstracts hyper from the actions is really cool (and I'm going to write quite a few clients in the future, that's why I'm asking 😉).

[cmbrandenburg]

@jgillich No, I haven't considered it, but I like the idea. What do you have in mind?

The main hurdle I see is that the Chill transport is tailored for CouchDB and doesn't extend to other applications. For example, see the with_revision_query. That method makes sense only in the context of CouchDB. How do we generalize the transport into a micro-framework useful for other APIs?

[jgillich]

I haven't entirely thought this through yet, but revision is a query parameter, right? You could assume standard HTTP types like query parameters and headers, which the transport could then use those to and construct a HTTP/WS/HTCPCP request or parse them right away for testing.

But I have to think about that for while, there probably is a better way.

[cmbrandenburg]

@jgillich I'm on board with the general idea. Any code in Chill that isn't fundamental to CouchDB is better off existing in another crate. However, I've got higher priorities and don't foresee working on this anytime soon. Feel free to take ownership of the idea and make it happen!

[cmbrandenburg]

@jgillich I opened #51, which, if it works out, might make the transport layer amenable to being separated into its own crate. It remains to be seen how useful such a “micro-framework” would be to other client-side HTTP libraries.