💥Breaking change in v0.22.1

[earthboundkid]

v0.22.1 removes .Get and .Post. In almost all cases, calls to these methods should be redundant and can be simply dropped. In the cases where it was not, use Method(http.MethodGet) or Method(http.MethodPost) instead.

[stephenafamo]

Why not also then drop other similar methods: Put(), Patch(), Head(), Delete()?

[earthboundkid]

I would like to have a better way of separating the “core” features from the convenient extras, but so far I’ve only been able to just move them to separate files. I tried to make them different types but that screwed up the method chaining. If you think of a better way to make it clear what it core and what’s extra, let me know.

[stephenafamo]

My suggestion would need a whole redesign.

That would be to use option arguments that satisfy the interface:

type BuilderOption interface {
    Apply(b *Builder)
}

Then instead of method chaining, it would have a constructor like:

func New(baseURL string, opts ...BuilderOption) *Builder {
    // ...
}

And then Builder will only have the other methods like Request(), Fetch() and Do().

This then allows for the following:

1. You can move all the helper options into a separate package. Or even create a whole new module for it.
2. Users of the package can create their own helper options to use with it.

[stephenafamo]

The developer experience of this method is quite similar.
Using this example from the README.

err := requests.
	URL("https://postman-echo.com/post").
	BodyBytes([]byte(`hello, world`)).
	ContentType("text/plain").
	Fetch(context.Background())

That becomes

err := requests.New(
            "https://postman-echo.com/post",
	    requests.BodyBytes([]byte(`hello, world`)),
	    requests.ContentType("text/plain"),
	).Fetch(context.Background())

If someone really wanted to make it look the same, they could use a dot import but I don't think that is necessary.

[earthboundkid]

Note that the Config function already does basically that. I should make it take a variadic slice of config functions instead of just one though. I’ve written about it elsewhere, so I won’t get into it here, but for this project I think the functional option pattern isn’t as good as method chaining.

[stephenafamo]

That makes sense.

Along with making it take a variadic slice, I think it would be better if Config was an interface rather than a raw function. Makes it generally easier to use IMO.

You can also add a ConfigFunc type which can satisfy the interface, similar to http.Handler and http.HandlerFunc