Support FormData requests

[cobbweb]

Would be neat to support FormData requests in a similar fashion to curl. I guess for the body: you could use a !formdata tag?

requests:
  upload_fish_image: !request
        method: POST
        url: "{{host}}/fishes"
        body: !formdata
          fish_id: "cod"
          fish_image: "@./cod_photo.jpg"

Not sure how viable this approach is, just wanted to get the conversation started :)

[LucasPickering]

I like this idea, a couple thoughts on your example:

• Correct me if I'm wrong, but I believe the @ syntax is specific to curl, and I assume you just pulled that in as an example. I would want to leverage the template/chain system for this, rather than introduce new syntax
• I'd like to lean on the Content-Type header rather than adding a tag to the body field. You'll need to submit Content-Type anyway to tell the server what you're sending.

With those in mind, here's what I'm thinking:

chains:
  cod_image: !file
    path: ./cod_photo.jpg
requests:
  upload_fish_image: !request
    method: POST
    url: "{{host}}/fishes"
    headers:
      Content-Type: multipart/form-data
    body:
      fish_id: "cod"
      fish_image: "{{chains.cod_image}}"

The changes I see immediately here that are needed to support this:

1. Binary templates. Right now templates have to resolve to strings. I believe we could update them to resolve to any arbitrary bytes without too much trouble, but I'd have to start poking around with that to be sure
2. body would have to support map values (right now it just supports strings)
3. We would need an additional adapter layer that uses the Content-Type header to map the structured body into bytes for the HTTP request.

• This would actually be useful beyond forms, because you could then use structured bodies for other content types, e.g. passing a map for application/x-www-form-urlencoded

4. This is specific to multipart/form-data, but we would need to add boundary values to the Content-Type header. Fortunately reqwest (the HTTP library that Slumber uses) will handle this for us.

In terms of difficulty/level of effort, I would rank these (most to least) as: 3, 4, 1, 2. It all seems pretty feasible to me though. Does this sound like it would solve your problem? If so I can write out some issues for this and get started on it.

[cobbweb]

I haven't used chains yet, but your proposed implementation looks wonderful!

You're right about the Content-Type header too, completely forgot about that. I think mutating it to handle the boundary is perfectly acceptable and expected.

[LucasPickering]

I thought about this a bit more and I think we actually want a hybrid solution: add a !form tag to the body field to define the structure of the body (so we can enforce it's actually a simple key-value pairing), then look at Content-Type to determine how to actually encode that structured body into the request. I've written up 3 issues to cover the work for this discussion: #242, #243, #244 (I already implemented support for binary templates). I'm going to close this and get started on the implementation, but feel free to reopen if there's open questions I missed.