19579Re: [rest-discuss] Media Type for resource archives
- Jan 10, 2014We (Jive) use the multipart/form-data in lots of use cases, such as uploading a document (with a well defined JSON format) plus some associated attachments. However, we don't enforce a requirement that the JSON data be the first body part -- instead, we search through the available body parts for it with some well-defined heuristics, and treat all the other body parts as attachments.Craig McClanahanOn Fri, Jan 10, 2014 at 2:35 PM, Jan Algermissen <jan.algermissen@...> wrote:
I am thinking about a media type for bundling together a bunch of resources into a single file. With these files I want to store a manifest file.
One option would be to just use a zip-based format and an manifest file with a well known name.
The problem with this is that useful stream processing of such a file can only be done by ensuring that the manifest is the first entry when unzipping. Apparently it requires some stunts to control the ordering of the zip entries and who knows whether the other end uses a compatible implementation.
Solution would be to unpack to disk first and go from there. Not nice.
A possible alternative would be to use a multipart format where I can simply require the manifest to be the first part. Then just zip that file or rely on transfer encoding to reduce the bytes on the wire.
Nice things about that:
- Ordering is guaranteed
- Full support for per-part MIME headers
- Content-Length enables fast splitting of the parts
- cid: URIs make for natural, standard URI-references inside the file
- stream processing without temporary storage
I am interested in reactions to the two alternatives or any ideas beyond that.
 Well, obviously their entities at some point in time
- << Previous post in topic Next post in topic >>