http-kit: Consider "easy" sync interface which does error handling for you, like clj-http?
I’m considering to adopt http-kit client in babashka so it can be used for scripting.
One thing that’s different in http-kit vs clj-http is that when used synchronously, you have to check for :error and/or :status and then throw yourself (or do some other handling). But this requires writing a bunch of boilerplate. I reckon every httpkit user has their own boilerplate for this.
That’s why I’m also considering adding a synchronous interface over httpkit, in a namespace called babashka.http-client which does deref for you, if there’s an :error, it will throw the error and it will also throw on a selection on status codes, like clj-http does, unless :throw is false. Is something like this maybe considered for httpkit proper?
If babashka users want the async httpkit, they can just use the existing http-kit namespaces.
I’m also considering to enable the SNI client by default, so that boilerplate isn’t needed either.
Please let me know if I’m overlooking something, I’ve only recently started looking at httpkit. I usually just want my script to exit with an error in case of a faulty request.
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 16 (5 by maintainers)
I think the conclusion of this issue reads: from http-kit’s perspective there isn’t a need for an “easy” “clj-http”-like interface, but from babashka there is. Therefore I will implement on babashka’s side as babashka.http.client (or babashka.http-client, the bikeshed jury is still out on that).
Btw, the above binaries also contain
org.httpkit.server: run a web server which starts in milliseconds 😃FWIW, my current take on this is the following:
So users have a choice to use either and there’s no need for wrapping anything.
The client is now part of these binaries:
Will release a new version probably this week.
About the above issue:
I found that
clj-httpbehaves the same:We can probably dismiss that as a weird edge case.