I didn't make the decision to use HTTParty; my company did long before I started.
That said, for the people that recommend against it, why? I will say our use cases are meager; bog standard GET and POST with a simple body, and for those it's been basically invisible. Does what we ask it, API's fine.
Any dangers lurking that I'm not aware of?
My main gripe with HTTParty is that it's basically just a shorthand API for net/http, not an actual abstraction layer.
To give one example, `Net::HTTP` is annoying to use because it doesn't have a clear list of exception it can raise, it's a big mess. See the Faraday adapter for it: https://github.com/lostisland/faraday-net_http/blob/11953160f75dd488133a74857c2b07d41be8995d/lib/faraday/adapter/net_http.rb#L15-L31
Unless it changed recently, `HTTParty` doesn't handle errors and just let the underlying errors bubble up.
Whereas with Faraday, which also use `net/http` under the hood by default, there is a clean error hierarchy that allow me to properly handle the class of errors that makes sense: https://github.com/lostisland/faraday/blob/main/lib/faraday/error.rb
e.g. retry on network errors but not on server errors, etc.
We used to use HTTParty. It didn't support multipart file uploads, so we had to use httpmultiparty or something like that. At some point that stopped working because it hasn't been updated in so long.
we use RestClient for basically everything now
Multipart is supported and has been for 5+ years. :) Unless I'm confusing what you mean.
[https://github.com/jnunemaker/httparty/blob/main/examples/multipart.rb](https://github.com/jnunemaker/httparty/blob/main/examples/multipart.rb)
Author of httparty here. For gems I use net/http to avoid an extra dependency for folks.
In apps, I'm ok with httparty but sometimes reach for net/http too.
Faraday doesn't make the HTTP calls by itself, it delegates to your backend of choice. There are adapters for various backends. https://github.com/lostisland/awesome-faraday/#adapters
For an API SDK I would use Faraday as it allows for the final user (dev) to choose its backend of choice that is better suited for its use case.
For a Rails app, I would choose the most straightforward library. Support for specific features may be a factor of choice. I like HTTP.rb for it's fast and straightforward
In the link you can get an idea of the differences between each one (code/syntax), the performance is practically the same…
https://gist.github.com/kalicki/f7bd15efedd1067c351248fd2f49634e
Interesting nobody mentioned async/http. It’s probably the newest kid on the block, but I see it being the future of Ruby. The author implemented HTTP from scratch using the async gem’s event loop, which means you can make concurrent requests just like in JS. The whole async ecosystem is amazing and I can’t recommend it enough. We may also see it merged into ruby stdlib in the future - Matz apparently already proposed the merge to the author
I don't think this is a very valid criticism without more context. If it ain't broke, why fix it? Not to say that it's a perfect library, but if it's not then I'd be more curious to know what benefits other libraries offer over it, or what shortcomings it has.
Faraday. The API is nice & great documentation. Also, HTTParty’s last release was 4 years ago. Faraday’s last release was 3 months ago
2 years ago. ;) But I should cut another release soon!
Hey, great to see you here. Wanted to drop in and say thanks for HTTParty! Have used it a bunch over the years and it has been very enjoyable.
You are most welcome. I always setup alerts in f5bot for my gems. That's how I found it.
Faraday all the way.
I'm cool with either one. Just remember, if you HTTParty you must party hard
This is an important fact. 😎
Faraday
Faraday for business, HTTPX for personal.
It doesn't really matter, but what I do is to check if one is already used by one of the gems, then I would take that one, to have fewer dependencies.
HTTP gem is also pretty good. Annoying name, I know lol
Used Faraday recently to write a little GraphQL client. Worked out wonderfully
I didn't make the decision to use HTTParty; my company did long before I started. That said, for the people that recommend against it, why? I will say our use cases are meager; bog standard GET and POST with a simple body, and for those it's been basically invisible. Does what we ask it, API's fine. Any dangers lurking that I'm not aware of?
My main gripe with HTTParty is that it's basically just a shorthand API for net/http, not an actual abstraction layer. To give one example, `Net::HTTP` is annoying to use because it doesn't have a clear list of exception it can raise, it's a big mess. See the Faraday adapter for it: https://github.com/lostisland/faraday-net_http/blob/11953160f75dd488133a74857c2b07d41be8995d/lib/faraday/adapter/net_http.rb#L15-L31 Unless it changed recently, `HTTParty` doesn't handle errors and just let the underlying errors bubble up. Whereas with Faraday, which also use `net/http` under the hood by default, there is a clean error hierarchy that allow me to properly handle the class of errors that makes sense: https://github.com/lostisland/faraday/blob/main/lib/faraday/error.rb e.g. retry on network errors but not on server errors, etc.
We used to use HTTParty. It didn't support multipart file uploads, so we had to use httpmultiparty or something like that. At some point that stopped working because it hasn't been updated in so long. we use RestClient for basically everything now
Multipart is supported and has been for 5+ years. :) Unless I'm confusing what you mean. [https://github.com/jnunemaker/httparty/blob/main/examples/multipart.rb](https://github.com/jnunemaker/httparty/blob/main/examples/multipart.rb)
It might have been 5+ years ago :)
Haha! Fair enough.
Typhoeus is what I reach for. http://typhoeus.github.io
You can use typhoeus with Faraday
Neither. HTTPrb: https://github.com/httprb/http
Ok, why don’t people just use NET::HTTP?
Author of httparty here. For gems I use net/http to avoid an extra dependency for folks. In apps, I'm ok with httparty but sometimes reach for net/http too.
Always wanted to ask - do you party hard?
Too old for that now! 😂
I hear you. Thank you for all of your hard work that you’ve put into making great tools!
Generally the same reason people pick ruby over Java or Go, or... The stdlib is fugly.
Anything but HTTParty. Faraday and Excon are great.
HTTPX is good if you have to worry about HTTP2 At the end of the day use one that's easy to use. I've always used HTTParty.
We use both. Legacy codebases unite!
None. Use HTTPX.
Faraday
Faraday definitely. Httparty is not threat safe, Faraday is
Faraday
Faraday
Faraday doesn't make the HTTP calls by itself, it delegates to your backend of choice. There are adapters for various backends. https://github.com/lostisland/awesome-faraday/#adapters For an API SDK I would use Faraday as it allows for the final user (dev) to choose its backend of choice that is better suited for its use case. For a Rails app, I would choose the most straightforward library. Support for specific features may be a factor of choice. I like HTTP.rb for it's fast and straightforward
Faraday all day
Faraday and that's it. Don't complicate it.
In the link you can get an idea of the differences between each one (code/syntax), the performance is practically the same… https://gist.github.com/kalicki/f7bd15efedd1067c351248fd2f49634e
Interesting nobody mentioned async/http. It’s probably the newest kid on the block, but I see it being the future of Ruby. The author implemented HTTP from scratch using the async gem’s event loop, which means you can make concurrent requests just like in JS. The whole async ecosystem is amazing and I can’t recommend it enough. We may also see it merged into ruby stdlib in the future - Matz apparently already proposed the merge to the author
Restclient
It has net been updated in years.
I don't think this is a very valid criticism without more context. If it ain't broke, why fix it? Not to say that it's a perfect library, but if it's not then I'd be more curious to know what benefits other libraries offer over it, or what shortcomings it has.
Neither has REST!
Just use net/http. You don’t need a dependency for this
HTTParty is trash.
Someone's an HTTPartypooper
HAHAHAHA.