Rework body handling to use providers

[jawher]

Hi !

Currently, sling only handles JSON, form and raw reader bodies.
These 3 types are hard coded in the Sling struct, by having one field for every type.

While it was still possible to send other types of bodies (xml, multipart, ...), their usage wasn't as fluent as the other 3 types.

This PR proposes the following:

• Introduce the BodyProvider interface
• Rework the existing supported types to use the interface above
• Add support for multipart and file upload using the same abstraction
• Keep the existing shortcut body methods to not break clients

Adding support for a new body types would not require touching the Sling struct. Simply a new implementation of the interface and maybe a factory function would do.

Users wanting to handle other types can simply implement the BodyProvider and use the API as seamlessly as the baked-in types:

sling.New().
        Post("http://localhost:4000/customer").
        BodyProvider(YamlBody(customer))
        ...

The code in this PR is not finished (it could use some more polish and tests).
I just wanted to get your feedback on this proposal before investing more time and effort on it.

[dghubble]

You can call it s.bodyProvider to avoid the double body awkwardness.

[dghubble]

nil is the default

[dghubble]

Thanks. I like the refactor in general, though I'd prefer the multipart code be split into a separate review. I'll set aside time to consider it in depth wrt. other APIs, whereas the refactor by itself to use BodyProvider is more straight forward to merge. Then in the short term you could use your customer Provider too.

How about sticking with io.Reader for now, I'm not sure the ReadCloser is needed for all bodies and it seems to be introduced for multipart.

[dghubble]

stdlib packages can all be clumped together

[jawher]

Thanks. I like the refactor in general, though I'd prefer the multipart code be split into a separate review. I'll set aside time to consider it in depth wrt. other APIs, whereas the refactor by itself to use BodyProvider is more straight forward to merge. Then in the short term you could use your customer Provider too.

Great ! I'll get working on it.

How about sticking with io.Reader for now, I'm not sure the ReadCloser is needed for all bodies and it seems to be introduced for multipart.

Actually I used io.ReaderColer because that was the type of the existing raw body field. But yeah, I can change to a simple io.Reader 👍

[dghubble]

Re-reading my original comment for Body, it looks like the reason for the io.ReadCloser was so

If the provided body is also an io.Closer, the request Body will be closed by http.Client methods.

rc, ok := body.(io.ReadCloser)
if !ok && body != nil {
    rc = ioutil.NopCloser(body)
}

I don't think a type assertion attempt and NopCloser wrap at the time of setting the body are required though. It looks like http.NewRequest does this already (perhaps it always did) https://golang.org/src/net/http/request.go?s=21674:21746#L680. So, I don't think io.ReadCloser would need to make its way into the BodyProvider and we're justified using io.Reader and it is simpler as you said.

[jawher]

@dghubble right !

I updated the PR to handle your feedback.

[dghubble]

Awesome. I've added a tweak in #25 to keep the BodyProvider implementations as an internal detail and a few minor things. Unless there are objections, I'll merge that tomorrow.

Thanks!

[dghubble]

Merged in #25