Mike picks out Net::HTTP as his prime example saying Its performance and API are just terrible but does not back his performance claims with any benchmarks and does not back up his API claims with any examples. The rest of his libraries fall under “old and crufty” but I’ve heavily used many of the libraries listed and don’t share those experiences.
via The Ruby Stdlib is not a Ghetto.
I have to mostly agree with Eric here. He adequately defends Net::HTTP’s performance. I just want to add that as an API it is also surprisingly complete and robust. Most of the libraries that have attempted to put a more convenient face on HTTP tend to fall flat on their faces when you want to do anything other than the most basic GETs and POSTs. It has separate error classes for all of the standard HTTP errors, making it very easy to handle errors in an idiomatic way. Modeling requests as objects in their own right may not seem like an immediately obvious approach, but it turns out to allow for a quite powerful way of incrementally building up requests. It may not always be the most intuitive library, but it’s rare that you hit on a case where the answer is “oh, we never thought of that use case”. That’s not something I can say of most libraries.
Avdi, thanks for the commentary – I appreciate the discussion. Here's a few issues I have with net/http. Here's the main simple method:
Net::HTTP.get_response(string_or_uri, path=nil, port=nil)
Just hardcoded parameters that don't allow much flexibility. Here's my suggested API:
This would be closer to open-uri's open and offers more flexibility via options with unnecessary optional params.
Net::HTTP.get_print – an API method just to puts the response? Superfluous.
Net::HTTP.get2 – terrible name
Net::HTTP.get – just returns the body string, not useful for anything real since you need the response to get headers and status code.
The fact that you have to set use_ssl manually despite having an HTTPS url/string is annoying: request.use_ssl = (url.protocol == 'https')
You may like the large class hierarchy representing HTTP responses, I think it's just overly OO/complex.
Hope this explains my POV a little better.
I agree that there are some warts in the API. I just think that when it comes to standard libs, in the continuum between “making easy things easy” and “making hard things possible”, the standard libraries should err on the side of “hard things possible”. I think Net::HTTP does this admirably/ I'm all in favor of 3rd party libs that put an “easy things easy” face on top of it for the simple cases.
P.S. I can understand accusing a project of complexity, but accusing a Ruby lib of being overly OO? That's a bit like accusing pie of being too delicious. Modeling things (including events) as objects is kind of the point in a pervasively OO language like Ruby.
I think in a perfect world I'd like an option in Net::HTTP to always just return the response rather than raising an error. But the fact that when it does raise an error, it's always a code-specific one which inherits from the more generic error family means that I can structure a nice rescue cascade from most specific to most general. That's a very convenient touch, and it's a step beyond what most libraries offer.