Closed xiaoyao1991 closed 3 years ago
Good overview. Base64 is already implemented by virtue of being able to store text in the database. The setField()
method can support any additional processing. Both multipart and multi-phase seem useful. I suggest we look (long-term) to support all methods of file uploading so the developer can choose the particular use-case that suits their needs.
@DeathByTape I agree so. I'm currently working on a proposal regarding necessary changes in elide to support multipart this week. I will think through more on multi-phase and maybe start with a couple of example queries first
Just dropping my 2 cents here: multiple HTTP requests does not seem that big a disadvantage when uploading files, as most of the time will be spent during the actual upload. The only exception would be a high-bandwidth but high-latency network, but it's not that common.
I think that file storage is a problem that Elide is not intended to solve, so fwiw I think that the only upload method that Elide should support is the Multiphase strategy. In that scenario the separate service would be responsible for creating/updating the metadata stored in Elide–so the flow would looks something like:
I think the real downside for multiple HTTP calls is not about performance, but consistency. Specifically, with multiple calls you don't get any transaction guarantees (like you would from, the JSON Patch ext, for instance). The caller would have to be responsible for ensuring metadata and file data is properly stored. If one or the other fails, they would need to manage the service appropriately from the client-side.
I suppose such a situation could lead to scenarios where malicious clients do horrible things to you data model but, perhaps, your permission model should gate this sort of abuse.
May I know if supporting file upload is still in Elide roadmap?
It is not on the roadmap.
I'm trying to draft the design of supporting file upload with metadata in Elide.
Motivation
Use cases(1, 2) are common of building a REST JSON API that allows for files to be uploaded with json documents describing the metadata.
An example is in an E-Commerce site, sellers may want to upload images for their products, and specify which products the images are related to.
Approaches
Base64 Way
The client encodes the files to be upload with Base64, and embed the Base64 string as a field in the JSON document.
The server receives the JSON document with Base64 data embedded, and applies additional processing logic (decoding from Base64, image resizing, saving to local filesystem, etc.)
Multipart Way
The client sends a
multipart/form-data
or amultipart/mixed
HTTP request instead ofapplication/vnd.api+json
. Have a part in the payload as the metadata part withContent-Type: application/vnd.api+json
. The rest of the payload can hold the file data.The server has to have endpoints configured to recognize
multipart/form-data
ormultipart/mixed
request type and parse the payload. This could be troublesome if it's a sub-resource (POST /product/1/images
).An example multipart request looks like:
Multi-phase(or Network Transaction) way
Inspired by Twitter API ,Youtube API, and this post. The idea is to sort of transactionize the process of file upload using in multiple HTTP calls. The procedure goes as follows:
X-Upload-Content-Length
header field to indicate the total accounted size of the content.Location
header which contains a tailored URL to the file upload endpointHandling Large Files (Chunking Mode)
In all case described above, the client can send the request with
Transfer-Encoding: chunked
to enable streaming mode.TODO:
Come up with an Elide change proposal of implementing some or all of the scenarios above.