Consider support for "multipart" requests

[jmdacruz]

I think this is really a stretch, but we recently ran into this situation and I think it's worthwhile mentioning: Imagine a situation in which you want to POST a binary file (e.g., image) which has metadata associated to it (e.g., image properties not in EXIF such as image description).

One of the ways of doing this is with a multipart POST request, one that has a JSON part (for the metadata of the image) and a binary part (for the image itself). This is possible with the current blueprint spec: you can set the Content-Type via "Request" to 'multipart/form-data;boundary="-----some-boundary-----"', and then just craft the body manually with the selected boundary and with each of the sections/parts having its own set of headers.

The problem with this, I think, is that you can't use MSON inside one of these parts, because you are already "inlining" the resource representation into the "Body" section.

Again, I don't see this is a must-have since there are other alternatives such as separating the metadata creation and the binary upload into two different operations (e.g., first create metadata and then upload binary using handle/token from POST result), but it was worth mentioning.

[zdne]

@jmdacruz interesting. If I understand it correctly you suggest an improvement where each (some) part(s) of a multipart message has its own MSON attributes. Correct?

If so please look at the issue #100 – and #100 (comment) in particular? Would having attributes under part section work?

[jmdacruz]

Yes, that would definite work. I also agree with some of the comments on the thread in that some of the attributes of each part could be abstracted away (e.g., the boundary could be defined for the entire message or even randomized)

[zdne]

also agree with some of the comments on the thread in that some of the attributes of each part could be abstracted away

@jmdacruz we best to add these comments there to bump it and make sure it won't get forgotten.