This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
[Feature]: Move checks for asset upload status into server endpoint #731
Labels
You can continue the conversation there. Go to discussion →
Currently, clients each implement their own logic to decide whether they should upload an asset to the server. After upload, the server then examines the asset again to determine whether it was indeed appropriate to be uploaded. This places copies of the relevant code in multiple places. Instead, the server should expose an endpoint for clients to ask whether a given asset should be uploaded. With that approach, all the relevant code for supported mimetypes and such can exist only serverside.
This endpoint should take an array request objects with metadata about the asset. Some optional?, some required!. I propose the following fields:
id!
- A unique id by which the client can identify the asset. Used only in the response to this request. (egce784cdd-f459-4d94-b557-9dd73d46cc56
)extension!
- The extension of the asset file (eg.jpeg
)mimetype!
- The mimetype of the asset file, as determined by the browser or a mimetype library (egimage/jpeg
)sha1?
- The sha1 hash of the file (93729ce956531f38867f78858023882147cdfe00
)deviceId?
- The id of the client device (same as current deviceId, maybe for bwcompat?)deviceAssetId?
- The id of the file as determined by the client platform (same as current deviceAssetId, maybe for bwcompat?)In response, the server should send an array with one object for each of the request objects, stating what action the client should take with that asset. Suggested:
id!
- The unique ID as sent by the client in the request, to identify the assetaction!
- The action to take on this asset.Accept
,Reject
(naming tbd? Can also beUpload
,Ignore
, etc)reason?
- If the asset is rejected, the reason why (Unsupported
,Duplicate
, etc)Here's an example request and response:
POST /api/v1/asset/prepareUpload
Response:
The text was updated successfully, but these errors were encountered: