does anyone have a example of uploading files with compojure-api that actually has more params than just the file? thinking a more complete form, like a document with a bunch of metadata…

@kennethkalmer Just add more params to :multipart-params

thanks! getting there, realized my mock request (ala peridot) was completely borked

Multipart params are a bit limited compared to JSON etc. as there is no arrays/objects, just param -> value

So if you need to pass more complex data, you might want to either separate file and data to two separate requests, or encode/parse data as transit/json in single multipart param yourself

I usually do the first myself. For example: 1. create image object with necessary metadata, 2. upload image file using ID from 1. request

I’m weary for the latter, don’t want entities built up in two steps and have to maintain this dependence between the two requests

I know multipart if very limited, will have to see how I go along

In one app I found the first better as it helped handling upload retries, as the app is often used on mobile network and images can be large.

yeah, I’m expecting quite large documents

if :multipart-params were also written into :body-params, one could use the new Coercion config in 2.0.0 to run for example string-coercion to the params.

... and that could be the new default?

hmmm, would have to play with it

my first intuition was to use :body and :multipart-params together, after realizing there isn’t a :multipart

ffs, this is a lost cause… gonna go for “direct to S3” approach with dev/test fallback and then post object key with form data

wasted too many many hours on this now

I think it should be possible to support JSON/Transit multipart params, but I don't think middlewares currently read these:

--Boundary
Content-Disposition: form-data; name="myJsonString"
Content-Type: application/json

{"foo": "bar"}
--Boundary
Content-Disposition: form-data; name="photo"
Content-Type: image/jpeg
Content-Transfer-Encoding: base64

<...JPEG content in base64...>
--Boundary

I think in such case you'd currently get a map with :content-type and :bytes or :filename (pointing to a temp-file) and would need to read and parse the contents

Parsing should be quite easy with muuntaja

Muuntaja could provide mutlipart-params store-fn which checks if the content-type is supported and parses the content, instead of creating byte-array/temp-file

If content-type is image or something Muuntaja doesn't support, it could create byte-array/temp-file like currently

for my tests I generated the multipart request with clj-http, passed it via ring-mock with all the correct details, but the ring.middleware.multipart-params didn’t parse it out correctly

adding some debug middleware before multipart-params showed the body was correct, still it didn’t work