1. I fully agree that HTTP error responses should be regular, non-exception objects. HTTP request mechanics such as DNS lookup, connection establishment, connection timeouts, etc. should be exceptions because they are unexpected. A complete HTTP response, regardless of its status, is not an exceptional situation: it is to be expected that an HTTP server can return a 500-coded response. Excon seems to get this right (although I’ll admit that it’s been a few years since I used it) and a variety of JVM HTTP clients get it right, too.
  2. Should a language’s standard library include an HTTP client? It sure is a convenience for one to be present out of the box, but quite frankly I don’t think I’ve ever used the one build into any language I’ve used with the sole exception of Net::Http in Ruby via open-uri. I feel like an HTTP client is ancillary, that it doesn’t really need to be included with the language’s distributable. It should almost always be an add-on module that can be updated and released more frequently than the core language itself. That decoupling could lead to greater collaboration from those who need an HTTP client and inspire less duplicated effort.

Written by

Scholar, bon vivant, champion of the oppressed. Pittsburgh-based software engineer+architect+consultant and community builder seeking serenity.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store