As cool (and pretty) as this is, I'm not sure I see the point to using this over each language's best native http client. As someone else said, Python's requests is fantastic, as is the mikeal/request library in node.<p>Point being, why would I choose this over a library which is hand-tailored to fit the idioms of the specific language its written for? What advantage does one get by forcing a relatively standard REST API across different languages?
Looks nice - but unfortunately as someone whose day-to-day language is python, I'll give up my requests library [1] when you pry it from my cold, dead hands.<p>[1]<a href="http://www.python-requests.org/en/latest/" rel="nofollow">http://www.python-requests.org/en/latest/</a><p>Not mine mine, it should be obvious. I'm not Kenneth Reitz.<p>In all seriousness, would be interested to hear about differences/benefits...
Looking at the examples for Node and PHP, those are essentially two different request libs with the same name. That lack of consistency is a problem - at the very least anyone thinking "porting this app to <language> will be easy because Unirest is available" will be in for a nasty surprise. At worst, it shows a lack of planning and a lack of communication within the Unirest team, and that's a <i>very</i> big problem for anyone relying on the code.<p>Moving forward, I'd recommend working very hard on unifying your featureset and API so it's consistent across all the versions.
Thanks for this. I'm already using Unirest.php to build a client library for my API and Unirest.rb is my obvious choice when I come to build the Ruby client lib.<p>As aroman said, some languages have nice built-in capabilities but some...just don't (PHP, I'm looking at you!). I love having this unified API which is very intuitive (especially when coming back to PHP after...7 years).<p>Keep up the good work!
You really need to make an effort to conform with established naming/casing conventions in each language [1]. For example, your example page should read [2] for .Net.<p>[1]: <a href="https://github.com/Mashape/unirest-net/blob/master/unirest-net/unirest-net/src/http/Unirest.cs" rel="nofollow">https://github.com/Mashape/unirest-net/blob/master/unirest-n...</a>
[2]: <a href="https://gist.github.com/jcdickinson/4dd0125d7c5af9d4878f" rel="nofollow">https://gist.github.com/jcdickinson/4dd0125d7c5af9d4878f</a>
The PHP version seems to be meh... Gotta do a lot to get us away from Guzzle. <a href="http://guzzlephp.org/" rel="nofollow">http://guzzlephp.org/</a>
I found code like ' int code = [response code];'
Why 'int' and not 'NSInteger'?<p>That being said, I've been looking for a <i></i>NotWorking replacement, and this might be it. Either this or I write my own once and for all.<p>Will give it a go!
Also; <a href="https://github.com/Mashape/unirest-obj-c/pull/8" rel="nofollow">https://github.com/Mashape/unirest-obj-c/pull/8</a>
This doesn't seem to be a good idea<p><pre><code> curl_setopt ($ch, CURLOPT_SSL_VERIFYPEER, false);
</code></pre>
<a href="https://github.com/Mashape/unirest-php/blob/master/lib/Unirest/Unirest.php#L98" rel="nofollow">https://github.com/Mashape/unirest-php/blob/master/lib/Unire...</a>
Minor nit, the ruby examples show:<p><pre><code> Unirest::post "http://httpbin.org/post", ...
</code></pre>
That syntax is deprecated, you should probably just use:<p><pre><code> Unirest.post "http://httpbin.org/post", ...
</code></pre>
I like the site though ;)
Interesting - does the Node version work if packaged for the browser i.e. by Browserify? Of course, there would be caveats, but it would seem like that would be very much in the spirit of this unified API.
I believe this the old unicorn library which was submitted here a few times in the past. <a href="http://getunicorn.io/" rel="nofollow">http://getunicorn.io/</a> I believe
The Java library's use of a static method makes it difficult to inject and mock out for tests, requiring a wrapper class to be written by hand to make such things possible.
I love Ruby so much that I shuddered a little when I saw the multi-line, multi-hash method call in the example code that made it look like js. Otherwise thumbs up.
Heh, platform-independence...I guess that's one way to get them to use <i>your</i> HTTP library, as opposed to the thousand other libs out there to do HTTP. ;)<p>But I like it! In all seriousness this is neat and I like the idea of ubiquitous library syntax, especially for new programmers (which there are a LOT of these days!). The API is reasonably simple and it's nice to have one less thing to look up when experimenting with a new language.
I recommend documenting that in PHP it's just a curl wrapper, as opposed to a lib that can work with curl, streams, etc... (nothing condescending on '"just" a wrapper'). Also give some insights on requirements (PHP 5.3+ I'd say?)
I actually used unirest.rb as one of the tools to teach my students about HTTP requests. I loved the clear syntax and found the experience a lot more straight-forward than many of the other HTTP libraries I came across. Thanks for putting this together!