<p>Hi everybody. </p>
<p>I would like to get some feedback on set of libraries that I wrote. Together
they are pluggable, middleware-based HTTP client.</p>
<p>Main idea is to replicate pattern from widely used for server implementation.
We all know (and love) <code>http.Handler</code> interface, which is a base for bunch of
libraries to extend on. I have also defined <code>Handler</code> interface, but one that
receives <code>context.Context</code> and <code>*http.Request</code> and returns <code>*http.Response</code> and <code>error</code>.
That is the base of the idea. Middlewares simply accept <code>Handler</code> and return
other <code>Handler</code>. With some utility stuff (like easy way for chaining middlewares,
simplified interface for writing of middlewares that only modify request or only
read response), that is full description of
<a href="https://github.com/delicb/cliware" rel="nofollow">cliware</a> library. (Name comes from CLIent middleWARE)</p>
<p>Based on cliware, I have written couple of (in my opinion) useful middlewares.
They are grouped in couple packages in <a href="https://github.com/delicb/cliware-middlewares" rel="nofollow">single repository</a>
There is support for authentication, path, cookie and query parameters manipulation, request and response body managing, retry...</p>
<p>On top of all that, as a glue and for nicer interface, I have written simple
http client. It is called <a href="https://github.com/delicb/gwc" rel="nofollow">GWC</a> (Go Web Client).</p>
<p>Main idea is to define reusable middlewares that can be applied to client (it
will be applied to all requests), group (it will be applied to all requests that
are part of same group) or request (only applied to single request). This should
make writing clients for large APIs easier and should remove a lot of boilerplate
code.</p>
<p>For full disclosure, I got an idea (and some middlewares implementation) from
excellent <a href="https://github.com/h2non/gentleman" rel="nofollow">h2non/gentleman</a> package. I was
missing context support (gentleman has context, but it is not <code>context.Context</code>
from standard library) and I had different idea how middlewares and composing
should be done.</p>
<p>I would really like to get some feedback, either on design, API, implementation,
anything really.</p>
<p>Thanks.</p>
<hr/>**评论：**<br/><br/>h2non: <pre><p>I'm the author of <code>gentleman</code>. I'm glad to see that it inspired other people creating its own solutions. At the end, that's one of the big potentials of the open source ecosystem: progressive enhancement, where reinventing the wheel is not implicitly bad.</p>
<p>I like the idea of reusable middlewares for HTTP clients, but unfortunately, there is no standard or idiomatic HTTP client oriented interface in Golang for what we can call as middlewares, as opposite to the server-side. That's why gentleman provides it's built-in middleware interface proposal. I like to think that gentleman was built with Go <code>net/http</code> idiomatic and friendly interfaces as much as possible.</p>
<p>I'm considering introducing support <code>context.Context</code> in gentleman <code>v2</code>, as well as other enhancements and interface design changes. However, I'm a bit busy these days and I don't expect to invest time on it at least in the next 3 months.</p>
<p>I will follow your project closely in order to see how it evolves.
I definitively think that middleware pattern can be perfectly extrapolated to other scenarios, not just server-oriented systems.</p>
<p>PS: I created another library before <code>gentleman</code> which also implements a client-side hierarchical middleware layer. It also inspired me to design gentleman in a better way. In case that you wanna take a look, here you go: <a href="https://github.com/h2non/theon" rel="nofollow">https://github.com/h2non/theon</a> </p></pre>
