<p>Which REST client library do you guys use?</p>
<ul>
<li><a href="https://github.com/dghubble/sling">sling</a></li>
<li><a href="https://github.com/levigross/grequests">grequests</a></li>
<li><a href="https://github.com/parnurzeal/gorequest">gorequest</a></li>
<li><a href="https://github.com/franela/goreq">goreq</a></li>
<li><a href="https://github.com/gosexy/rest">gosexy's rest</a></li>
<li><a href="https://github.com/jmcvetta/napping">napping</a> - Is out of the question because of the GPL license</li>
</ul>
<p>Anything else? net/http?</p>
<p>The one "special" thing I need is access to the raw bytes because it's being sent as protobuf - but I'll assume every library has this feature.</p>
<p>Thanks!</p>
<p>Edit: Looks like I'll be going with net/http. I did play around with sling but didn't grok it - I struggled with printing the json from <a href="http://ip.jsontest.com">http://ip.jsontest.com</a>. OTOH, gorequst just worked for me... couldn't be easier.</p>
<hr/>**评论：**<br/><br/>usernameliteral: <pre><p>Just use <code>net/http</code>.</p></pre>gogroob: <pre><p>I second this. I wrote a client library recently <a href="https://github.com/whitby/vcapi">https://github.com/whitby/vcapi</a> and you don't need anything beyond 'net/http'</p>
<p>The godo client library for DigitalOcean is a great reference for how to create your own.
<a href="https://github.com/digitalocean/godo">https://github.com/digitalocean/godo</a> </p></pre>7834: <pre><p>seems to be the popular choice - thanks.</p>
<p>I guess I'm used to other languages where the std libs are lacking. net/http doesn't look hard to use - just more boiler plate.</p></pre>SurplusSix: <pre><p>Also agree, I just started a piece of work interacting with a rest api. Initially I tried one of the libraries but it didn't really make things that much easier SSSI switched back to just net/http, also don't forget there is a cookie jar available too if you need it, really helped me out.</p></pre>cyrusol: <pre><p>While <code>net/http</code> is a viable choice most of the time, I (not the OP) want to make a program that uses <em>many</em> APIs (somewhere between 10 and 100). Some kind of abstraction <em>is</em> useful. Heck, I might just write my own because that way I only depend on the standard library anyway. But still, isn't there an "everybody's favorite" out of the listed libs in the OP?</p>
<p>Isn't there some kind of canonical, recommended architecture for an API client? Like an RFC for Rest APIs?</p></pre>usernameliteral: <pre><blockquote>
<p>Some kind of abstraction is useful.</p>
</blockquote>
<p>Yes, write an API-specific client with <code>net/http</code>. I don't see how a adding another layer of general HTTP client functionality is going to help you. If you find yourself repeating a lot of code in the calls to each API, write a function—it'll do exactly what you want and no more.</p></pre>daveddev: <pre><p>I met Dalton (sling author) at the recent Gophercon. He seems to have his head on straight and is very intelligent. If net/http isn't convenient in your case, I'd start with sling and consider others if I wasn't finding what I needed.</p>
<p>... so long as it's understood that you're generally trading one person's opinion of ease (and a dependency) for simplicity. In other words, you're layering over the standard library with some complexity/boilerplate in order to access an alternate (easier?) API which may or may not decrease development/maintenance time. The best approach is to know exactly why you're using a framework, server or client. If you don't know exactly why, favor the standard library.</p>
<p>I encourage you to compare the code yourself:</p>
<p><a href="http://www.freenerd.de/accessing-the-github-api-with-golang/">http://www.freenerd.de/accessing-the-github-api-with-golang/</a></p>
<p><a href="https://github.com/dghubble/sling/blob/master/README.md#usage">https://github.com/dghubble/sling/blob/master/README.md#usage</a></p>
<p>There are trade-offs to be keenly aware of. Make your own judgment carefully and enjoy working in a great language. If you need help, someone is usually available on #go-nuts, but be prepared with, preferably, running code on <a href="http://play.golang.org">http://play.golang.org</a>.</p></pre>7834: <pre><p>Thanks for this. Yea, I don't know. I tried sling but I failed at doing the most basic thing - printing the json returned from <a href="http://ip.jsontest.com" rel="nofollow">http://ip.jsontest.com</a> (which seems down now - ugh).</p>
<p>I guess the trade off is 1) external dependency vs 2) more boiler plate code. Hmm. net/http looks easy enough to start with. This for the comment! </p></pre>newimprovedoriginal: <pre><p>I would say net/http, except it lacks in the routing department, so suggest httprouter (<a href="https://github.com/julienschmidt/httprouter" rel="nofollow">https://github.com/julienschmidt/httprouter</a>) + a lightweight middleware package (<a href="https://github.com/laicosly/restiful" rel="nofollow">https://github.com/laicosly/restiful</a>)</p></pre>usernameliteral: <pre><p>He said client, not server.</p></pre>newimprovedoriginal: <pre><p>haha, details, what details? </p></pre>google_you: <pre><p>if your REST service is over http, there's net/http plus hypermedia parser of your choice.</p>
<p>Which hypermedia are you using for representation?</p></pre>brianXQ3: <pre><p>Which hypermedia parsers for Go do you recommend?</p></pre>google_you: <pre><p>There's net/html , encoding/json for application/hal+json, encoding/xml for application/atom+xml</p></pre>klaaax: <pre><p>you definitely don't need or want a "rest client library" with Go. net/http is the only abstraction you'd want to use. With Go you really need to restrict the number of dependencies you need to rely on.</p></pre>sethammons: <pre><p>Echoing @usernameliteral, why not use the std lib net/http?</p></pre>TheMue: <pre><p><a href="https://godoc.org/github.com/tideland/golib/web" rel="nofollow">https://godoc.org/github.com/tideland/golib/web</a></p></pre>
