script

script copied to clipboard

There has been some valuable proposal work and prototyping on HTTP support for script, notably in #3, #73 , and #72. However, I haven't yet seen a design that looks obvious, and that's how I want it to be: so simple that when you see it, you think "Of course! That's the only way it could work."

Opening this yet-another-issue to track a new approach to HTTP support: not "what could we reasonably include?", but "what could we not reasonably leave out?"

What if the API were func HTTP(baseurl string, options ...HTTPOptions) *Pipe? HTTPOptions could default to GET, reject non-2XX, no special headers, no body, but let users provide those by passing in options. For things like users wanting to get the status code there could be a generic callback options like func HTTPHandler(func (*http.Response, *http.Request) error) HTTPOption to let users do whatever post-processing before the pipe that they want.

That's nice, but the addition of options makes it extremely complicated. In general, script is designed to help you quickly write concise programs that do fairly simple things. It's assumed that in the complicated case you won't mind writing normal Go code, which is very good at that kind of thing.

I'd like to try out a few ideas for HTTP support and kick the tyres on them a bit, to see how much of the common use cases they cover without options.

Hey @bitfield @carlmjohnson, I submitted PR-136 and wanted to see if this should do. This currently supports GET requests but I can extend it to support all other HTTP Verbs, authentication, etc.

Here's an example request - statusCode, body, err := script.Http("https://postman-echo.com/get?foo1=bar1&foo2=bar2").Get()

Looking forward to your feedback.

Thanks, @M3talM0nk3y! How do you see this integrating with the other pipe-based operations in script? For example, how would you pipe the HTTP response into a JQ query?

Done (at last!) in #139, and thanks to everyone here for their valuable input in hashing out this design.