Parse headers, return response map about babashka.curl HOT 7 CLOSED

The example code you shared works really well 👍. Are you looking for contributions to get this into the repo?

from babashka.curl.

@rymndhng Yep, you can go ahead with a PR that implements this. To not break existing code, what would be a good option to state that you want a response map instead of only the body? Maybe something like (curl/get ... {:response true}) => {:headers .. :body .. :status ..}? Other ideas welcome.

cc @dainiusjocas

from babashka.curl.

The example code is naive and shouldn't very performant but for the first iteration might be good enough :)

from babashka.curl.

+1 on retaining the existing interface. The current API of returning stdout of the subprocess is appropriate given the ability to modify args with :raw-args.

To support response parsing, the change will involve modify the incoming opts property to add --I and transform the response. This to me hints the solution can be expressed elegantly with a middleware pattern.

With this in mind, perhaps we should consider adding a new namespace babashka.curl.client which works with response maps. This is similar to how cli-http organizes with cli-http.client as the higher level interface and cli-http.core as the lower level interface that translates to/from the java api.

from babashka.curl.

I'd rather focus on just the current feature:

Implement an option to get back the headers + body separately.

Also I'd rather keep this in one single namespace for now

from babashka.curl.

Fair point 👍

It occurred to me that the use-case for babashka.curl is just enough wrapping to be easy to work with. There are other libraries out there for the entire batteries-included http client.

from babashka.curl.

Yeah and we can always do middleware kind of stuff later on. To be honest, I've only used middleware once or twice with clj-http, so I'd say it won't be that common for scripting use cases.

from babashka.curl.