twm
commented
3 years ago Right now data + files does have meaning: data must be a dict or sequence of (param name, value) tuples. These are added to the multipart/form-data request body before the files (they populate the fields parameter of treq.multipart.MultiPartProducer along with any other files).
To craft a multipart/mixed body I think you'd do best to create an IBodyProducer implementation that produces the MIME boilerplate, the JSON part, and then delegates to MultiPartProducer. Such an implementation would be a reasonable addition to treq.
It is a bit confusing that data functions as both the "I want to fully control the request body" and a convenience wrapper for application/www-form-urlencoded and multipart/form-data key/value items. I suppose that design error was inherited from requests.
There are some API services out there in the wild that require a content-type of "multipart/mixed", so that a POST may contain, for example, a JSON payload and a binary image.
treq inspects the kwargs for a POST, and if it finds "data", it sets the content-type to "application/x-www-form-urlencoded"; if it finds "files", it sets the content-type to "multipart/form-data". In order to support "multipart/mixed", treq could probably add a conditional check for "data and files", which if true would generate the appropriate request header and body.