Fork me on GitHub
#ring-swagger
<
2017-07-03
>
kennethkalmer15:07:39

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…

juhoteperi15:07:41

@kennethkalmer Just add more params to :multipart-params

kennethkalmer15:07:12

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

juhoteperi15:07:55

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

juhoteperi15:07:41

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

juhoteperi15:07:51

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

kennethkalmer15:07:34

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

kennethkalmer15:07:54

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

juhoteperi15:07:02

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.

kennethkalmer15:07:39

yeah, I’m expecting quite large documents

ikitommi16:07:23

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.

ikitommi16:07:23

... and that could be the new default?

kennethkalmer16:07:56

hmmm, would have to play with it

kennethkalmer17:07:42

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

kennethkalmer18:07:29

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

kennethkalmer18:07:47

wasted too many many hours on this now

juhoteperi18:07:37

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

juhoteperi18:07:23

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

juhoteperi18:07:31

Parsing should be quite easy with muuntaja

juhoteperi18:07:53

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

juhoteperi18:07:19

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

kennethkalmer21:07:45

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

kennethkalmer21:07:24

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