You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One request for all files (might be easier handling on consumer side)
Increases file size by about 33% (👎 bad for big files, 🤷 does not matter much for small files and low traffic)
If POST transfers back a processed result, this might lead to a synchronous style which is not very REST-y. (But also might be acceptable, because it is easier; and does not matter if no scalability is required)
With a synchronous style, server can just delete all files after processing (or only retain the result file).
Multiple POST
$ curl -X POST -d @file1 -H http://localhost/files/
$ curl -X POST -d @file2 -H http://localhost/files/
Transfering each resource on its own is more REST-y
If file processing is wanted, an additional GET is needed (and probably some description file which points to all previously uploaded files).
If files are only needed temporarily, server has to handle some garbage collection.
Multipart
Content-Type: multipart/form-data; boundary=12345
--12345
Content-Disposition: form-data; name="sometext"
some text that you wrote in your html form ...
--12345
Content-Disposition: form-data; name="name_of_post_request" filename="filename.xyz"
content of filename.xyz that you upload in your form with input[type=file]
--12345
Content-Disposition: form-data; name="image" filename="picture_of_sunset.jpg"
content of picture_of_sunset.jpg ...
--12345--
Sometimes badly supported by libraries.
Not very intuitive and beautiful; rather error prone.
No idea if a path separator in filename would be legal.
A simple HTML page without JavaScript could be used to transfer data.