File uploads for both attachment fields and file collections can be handled via the HTTP API. The method of invocation differs depending on the storage engine used by the attachment or file collection.
For built-in open-source storage engines like S3, OSS, and COS, the HTTP API call is the same as the one used by the user interface upload feature, where files are uploaded through the server. API calls require a user-based JWT token to be passed in the Authorization request header; otherwise, access will be denied.
Initiate a create action on the attachments resource (attachments) by sending a POST request and upload the binary content through the file field. After the call, the file will be uploaded to the default storage engine.
To upload files to a different storage engine, you can use the attachmentField parameter to specify the storage engine configured for the collection field. If not configured, the file will be uploaded to the default storage engine.
Uploading to a file collection will automatically generate a file record. Initiate a create action on the file collection resource by sending a POST request and upload the binary content through the file field.
When uploading to a file collection, there is no need to specify a storage engine; the file will be uploaded to the storage engine configured for that collection.
For S3-compatible storage engines provided through the commercial S3-Pro plugin, the HTTP API upload requires several steps.
Get storage engine information
Initiate a getBasicInfo action on the storages collection (storages), including the storage name, to request the storage engine's configuration information.
Example of returned storage engine configuration information:
Get the presigned URL from the service provider
Initiate a createPresignedUrl action on the fileStorageS3 resource by sending a POST request with file-related information in the body to obtain the presigned upload information.
Note:
name: File namesize: File size (in bytes)type: The MIME type of the file. You can refer to Common MIME typesstorageId: The ID of the storage engine (theidfield returned in step 1).storageType: The type of the storage engine (thetypefield returned in step 1).Example request data:
The data structure of the obtained presigned information is as follows:
Upload the file
Use the returned putUrl to make a PUT request, uploading the file as the body.
Note:
putUrl: TheputUrlfield returned in the previous step.file_path: The local path of the file to be uploaded.Example request data:
Create the file record
After a successful upload, create the file record by initiating a create action on the attachments resource (attachments) with a POST request.
Explanation of dependent data in
data-raw:
title: ThefileInfo.titlefield returned in the previous step.filename: ThefileInfo.keyfield returned in the previous step.extname: ThefileInfo.extnamefield returned in the previous step.path: Empty by default.size: ThefileInfo.sizefield returned in the previous step.url: Empty by default.mimetype: ThefileInfo.mimetypefield returned in the previous step.meta: ThefileInfo.metafield returned in the previous step.storageId: Theidfield returned in step 1.Example request data:
The first three steps are the same as for uploading to an attachment field. However, in the fourth step, you need to create the file record by initiating a create action on the file collection resource with a POST request, uploading the file information in the body.
Explanation of dependent data in
data-raw:
title: ThefileInfo.titlefield returned in the previous step.filename: ThefileInfo.keyfield returned in the previous step.extname: ThefileInfo.extnamefield returned in the previous step.path: Empty by default.size: ThefileInfo.sizefield returned in the previous step.url: Empty by default.mimetype: ThefileInfo.mimetypefield returned in the previous step.meta: ThefileInfo.metafield returned in the previous step.storageId: Theidfield returned in step 1.Example request data: