myQNAPcloud Object S3 API Guide

myQNAPcloud Object is a cloud-based object storage service designed to provide high-performance, reliable, and secure data storage for a broad range of applications and use cases. This service is built to be fully compatible with the Amazon Web Service Simple Storage Service (AWS S3) API, ensuring seamless integration with S3-compatible applications and gateway devices.

myQNAPcloud Object is tailored for individuals and organizations seeking a cost-effective and efficient data storage infrastructure. Designed to work with S3-compatible applications, myQNAPcloud Object enables users to leverage familiar tools and workflows while benefiting from the reliability and flexibility of QNAP’s ecosystem.

• Compatibility: myQNAPcloud Object is designed to be fully compatible with the AWS S3 API, ensuring that existing AWS S3-compatible applications can work seamlessly.
• Performance: myQNAPcloud Object offers a high-performance storage solution optimized for reliability and efficiency.

While myQNAPcloud Object aligns closely with AWS S3, certain features may have been enhanced or implemented differently. This guide aims to clarify these nuances to help users maximize the potential of myQNAPcloud Object.

This guide uses examples involving access to buckets in specific myQNAPcloud Object regions. For more information about region-specific endpoints and service URLs, see "Service URLs for myQNAPcloud Object Storage Regions".

Host Designation

myQNAPcloud Object supports both path-style and virtual-style requests, similar to AWS S3. A unique host name is required (for example, s3.us-east-1.myqnapcloud.io versus s3.amazonaws.com). We recommend using path-style requests, as shown in all examples in this guide (e.g., http://s3.us-east-1.myqnapcloud.io/my-bucket/my-object) because path-style requests provide greater flexibility in bucket naming, avoiding domain name conflicts.

Always Consistent

Unlike the strong consistency model of AWS S3, myQNAPcloud Object provides an "always consistent" view of all operations. This ensures that any operation following another will produce consistent results. For instance, after deleting an object (DELETE operation), performing a subsequent HEAD request will always confirm the object's deletion, eliminating the need for additional programming to wait for operation completion.

Authenticating Requests

myQNAPcloud Object supports both autonomous and signature versions 2 and 4, compatible with AWS S3, for headers and query parameters. While signature version 4 offers better security, it requires more computational resources due to the overhead of calculating the SHA256 hash. If performance is critical, signature version 2 may be used, with MD5 (returned as the ETag header) ensuring data integrity.

For version 4 signing requests, all regions are supported for myQNAPcloud Object signing requests.

myQNAPcloud Object does not support signature signing for browser-based uploads or HTML form requests, as these operations are not currently supported.

For version 2 signing, the following sub-resource keys are specified as query parameters in requests:

• append
• compose
• force_delete=true

These query parameters must be included when calculating the signature for PutObject and DeleteBucket operations.

Error Responses

Wherever possible, myQNAPcloud Object uses error responses compatible with AWS S3. Additional error codes may also be provided for enhanced functionality.

HTTP Error Codes

TCP Error Codes

myQNAPcloud Object supports the following TCP error codes:

• Unexpected EOF
• Broken Pipe
• Connection reset by Peer

Not Supported in myQNAPcloud Object

Operations on buckets include: deleting, renaming, and logging buckets as well as cross-origin resource sharing (CORS) support, lifecycle policy, object locking, and compliance.

Force Delete Bucket

AWS S3 will not allow you to delete a bucket if it contains objects that have not been deleted.

myQNAPcloud Object provides a force delete option that first deletes all the objects in the bucket and then deletes the bucket. The deletion of objects is subject to policy and compliance requirements on the bucket.

To use the force delte option, simply add it as a query string. For example:

DELETE http://s3.us-east-1.myqnapcloud.io/my-bucket?force_delete=true HTTP/1.1

Renaming a Bucket

AWS S3 does not support renaming of buckets. It only supports renaming of objects in a bucket.

myQNAPcloud Object supports the renaming of buckets. The new bucket name must not be in use for the renaming to be successful. The caller must have the s3:CreateBucket policy permission to rename a bucket.

To rename a bucket, use the HTTP method MOVE along with the header field “Destination” to give the new bucket name. For example: 

MOVE http://s3.us-east-1.myqnapcloud.io/my_old_bucket HTTP/1.1
Destination: my_new_bucket

MFA (Multi-Factor Authentication) Delete

myQNAPcloud Object supports the “x-amz-mfa” header while:

• configuring versioning on a bucket, or
• deleting objects with object deletion requests compatible with AWS S3.

myQNAPcloud Object does not require the “x-amz-mfa” header if the user's access credentials signing the request were authenticated with MFA. myQNAPcloud Object only supports virtual MFA devices.

Maximum Number of Buckets

Standard AWS S3 supports only 100 buckets.

myQNAPcloud Object allows for a maximum of 1000 buckets per account and this number may be increased by contacting myQNAPcloud Object Customer Support.

Bucket Logging

myQNAPcloud Object supports bucket logging, which creates a text log file of all access to a bucket. The format of the log file is identical to the AWS S3 log file.

myQNAPcloud Object bucket logging does not require any ACL permission settings to store logs in a target bucket. Although you can give permission settings in the logging request or in an ACL, they are not required for logging to work in myQNAPcloud Object. However, the bucket that is a target for log files must be inside the same account as the bucket being logged.

Bucket Cross-Origin Resource Sharing (CORS) Support

For compatibility with browser access to myQNAPcloud Object as a web server, the myQNAPcloud Object server will return CORS headers when the header “Origin” is given in an HTTP request. Additionally, the server supports the HTTP method OPTIONS on either buckets or objects to return the CORS headers needed for a browser pre-flight test before accessing myQNAPcloud Object.

Different from AWS, myQNAPcloud Object returns the settings that will allow the browser full access to myQNAPcloud Object. Hence, myQNAPcloud Object does not support the AWS functions that allow a PUT and GET on a bucket with the “cors” parameter in the URL. Note that allowing browser full access to data does not affect the security of access to any objects and all access policies will still be enforced.

The following are the HTTP headers returned by default when the header “Origin” is given in an HTTP request:

Access-Control-Allow-Headers: *
Access-Control-Allow-Methods: GET, HEAD, POST, PUT, DELETE, MOVE, OPTIONS
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: *
Access-Control-Max-Age: 86400

Lifecycle Policy

The Lifecyle feature establishes a Lifecycle policy with rules to define actions that you want myQNAPcloud Object to take during the life of an object. This feature replaces the need to manually delete an object after a retention period.

Configuring Lifecycle Settings 

The lifecycle settings for a bucket are configuring with the "put-bucket-lifecycle-configuration" command. For example: 

$ aws s3api put-bucket-lifecycle-configuration --bucket 1-1-1-1 --endpoint-url https://s3.us-east-1.myqnapcloud.io --lifecycle-configuration file://lifecycle.json
{

    "Rules": [
        {
            "Expiration": {
                "Days": 1
            },
            "ID": "lifecycle_rule_1",
            "Filter": {
                "And": {
                    "ObjectSizeGreaterThan": 1,
                    "ObjectSizeLessThan": 21474836480
                }
            },
            "Status": "Enabled"
        },
        {
            "Expiration": {
                "Days": 1
            },
            "ID": "object_lifecycle_rule_bucket_6807766",
            "Filter": {
                "Prefix": "1"
            },
            "Status": "Enabled"
        }
    ]
}

Here is another example:  

PUT https://s3.us-east-1.myqnapcloud.io/1-1-1-1?lifecycle
<LifecycleConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
    <Rule>
        <Expiration>
            <Days>1</Days>
        </Expiration>
        <ID>lifecycle_rule_1</ID>
        <Filter>
            <And>
                <ObjectSizeGreaterThan>1</ObjectSizeGreaterThan>
                <ObjectSizeLessThan>21474836480</ObjectSizeLessThan>
            </And>
        </Filter>
        <Status>Enabled</Status>
    </Rule>
    <Rule>
        <Expiration>
            <Days>1</Days>
        </Expiration>
        <ID>object_lifecycle_rule_bucket_6807766</ID>
        <Filter>
            <Prefix>1</Prefix>
        </Filter>
        <Status>Enabled</Status>
    </Rule>
</LifecycleConfiguration>

There is no response body for this call.

Retrieving Lifecycle Settings

The lifecycle settings for a bucket can be retrieved with the "get-bucket-lifecycle-configuration" command. For example:

$ aws s3api get-bucket-lifecycle-configuration --bucket 1-1-1-1 --endpoint-url https://s3.us-east-1.myqnapcloud.io
{
    "Rules": [
        {
            "Expiration": {
                "Days": 1
            },
            "ID": "lifecycle_rule_1",
            "Filter": {
                "And": {
                    "ObjectSizeGreaterThan": 1,
                    "ObjectSizeLessThan": 21474836480
                }
            },
            "Status": "Enabled"
        },
        {
            "Expiration": {
                "Days": 1
            },
            "ID": "object_lifecycle_rule_bucket_6807766",
            "Filter": {
                "Prefix": "1"
            },
            "Status": "Enabled"
        }
    ]
}

Here is another example:

GET https://s3.us-east-1.myqnapcloud.io/1-1-1-1?lifecycle
<?xml version="1.0" encoding="UTF-8"?>
<LifecycleConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
    <Rule>
        <Expiration>
            <Days>1</Days>
        </Expiration>
        <ID>lifecycle_rule_1</ID>
        <Filter>
            <And>
                <ObjectSizeGreaterThan>1</ObjectSizeGreaterThan>
                <ObjectSizeLessThan>21474836480</ObjectSizeLessThan>
            </And>
        </Filter>
        <Status>Enabled</Status>
    </Rule>
    <Rule>
        <Expiration>
            <Days>1</Days>
        </Expiration>
        <ID>object_lifecycle_rule_bucket_6807766</ID>
        <Filter>
            <Prefix>1</Prefix>
        </Filter>
        <Status>Enabled</Status>
    </Rule>
</LifecycleConfiguration>

Deleting Lifecycle Settings

The lifecycle settings for a bucket can be deleted with the "delete-bucket-lifecycle" command. For example:

$ aws s3api delete-bucket-lifecycle --bucket 1-1-1-1 --endpoint-url https://s3.us-east-1.myqnapcloud.io

There is no response body for this call.

Object Lock

myQNAPcloud Object supports an object lock that prevents the deletion or overwrite of object versions for a fixed amount of time or indefinitely.

The object lock settings for a bucket are specified using the “?object-lock” query string along with the object lock settings as the XML body in the request. For example:

PUT https://s3.us-east-1.myqnapcloud.io/qa.objectlock.002/?object-lock HTTP/1.1
<ObjectLockConfiguration>
     <ObjectLockEnabled>Enabled</ObjectLockEnabled>
     <Rule>
          <DefaultRetention>
               <Mode>COMPLIANCE</Mode>
               <Days>10</Days>
          </DefaultRetention>
     </Rule>
</ObjectLockConfiguration>

The object lock settings for a bucket can be retrieved by getting the bucket with the “?object-lock” query string. For example:

GET https://s3.us-east-1.myqnapcloud.io/qa.objectlock.002/?object-lock HTTP/1.1

Response body:

<?xml version="1.0" encoding="UTF-8"?>
<ObjectLockConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
     <ObjectLockEnabled>Enabled</ObjectLockEnabled>
     <Rule>
          <DefaultRetention>
               <Mode>COMPLIANCE</Mode>
               <Days>10</Days>
          </DefaultRetention>
     </Rule>
</ObjectLockConfiguration>

There are also object lock settings for each object described in Operations on Objects.

The object lock settings for a bucket can be cleared using "?object-lock" query string. For example:

PUT https://s3.us-east-1.myqnapcloud.io/qa.objectlock.002/?object-lock HTTP/1.1

Response body:

<ObjectLockConfiguration>
     <ObjectLockEnabled>Enabled</ObjectLockEnabled>
          <Rule>
               <DefaultRetention>
                    <Mode></Mode>
                    <Days></Days>
          </DefaultRetention>
     </Rule>
</ObjectLockConfiguration>

myQNAPcloud Object Compliance

myQNAPcloud Object supports a compliance policy that prevents the deletion of objects and provides additional information to prove that the original data is not modified since the time written. The compliance feature may be required for certain regulatory needs, but is also useful to prevent accidental data deletion.

Compliance is different from the object locking setting for a bucket.

You can set the compliance policy on any bucket controlling all the objects that are stored in that bucket. Specify the bucket compliance policy with the following XML tags.

The compliance settings for a bucket are specified using the “?compliance” query string along with the compliance settings as the XML body in the request. For example:

PUT http://s3.us-east-1.myqnapcloud.io/my-bucket?complianceHTTP./1.1
<BucketComplianceConfiguration>
     <Status>enabled</Status>
     <LockTime>off</LockTime>
     <RetentionDays>365</RetentionDays>
     <DeleteAfterRetention>true</DeleteAfterRetention>
</BucketComplianceConfiguration>

After compliance is enabled for a bucket, the policy is immediately applied to all objects in the bucket. An attempt to delete an object before the retention period will return an error.

The compliance settings for a bucket can be retrieved by getting the bucket with the “?compliance” query string. For example:

GET http://s3.us-east-1.myqnapcloud.io/my-buck?complianceHTTP/1.1

Response body:

<BucketComplianceConfiguration xml ns="http://s3.amazonaws.com/doc/2006-03-01/">
     <Status>enabled</Status>
     <LockTime>2016-11-07T15:08:05Z</LockTime>
     <IsLocked>false</IsLocked>
     <RetentionDays>0</RetentionDays>
     <ConditionalHold>false</ConditionalHold>
     <DeleteAfterRetention>false</DeleteAfterRetention>
</BucketComplianceConfiguration>

There are also compliance settings for each object described in Operations on Objects.

Operations on Buckets Not Supported in myQNAPcloud Object

Operations on Objects include renaming, composing, appending, and deleting objects as well as encryption, storage class, object locking, and compliance.

Renaming Objects

myQNAPcloud Object supports functionality to move an object-in effect, renaming the object by changing the key. This eliminates the two-step process of first copying an object and then deleting the original object. The caller must have s3:PutObject policy permission on the bucket to rename objects.

To rename objects, use the HTTP method MOVE along with the following parameters in the request headers that affect the move operation.

The call will return the results as an XML body of the response. The results include the following for each object renamed:

• original source key,
• renamed destination key,
• version ID of the object, and
• any error in the rename operation.

The quiet option will cause the results to list only the keys that encountered an error.

Below is an example, which renames all objects that start with the prefix “TestMove-Dir2/” to have the new prefix “TestMove-Dir2-Renamed/

MOVE http://s3.us-east-1.myqnapcloud.io/my_bucket/TestMove-Dir2/HTTP/1.1 Destination:TestMove-Dir2-Renamed/X-Wasabi-Prefix:true

Response body:

<MoveObjectResult> <SourcePrefix>TestMove-Dir2/SourcePrefix> <DestinationPrefix>TestMove-Dir2-Renamed/DestinationPrefix> <MoveObject> <SourceKey>TestMove-Dir2/SourceKey> <DestinationKey>TestMove-Dir2-Renamed/DestinationKey> MoveObject> <MoveObject> <SourceKey>TestMove-Dir2/Dir1/SourceKey> <DestinationKey>TestMove-Dir2-Renamed/Dir1/DestinationKey> MoveObject> <MoveObject> <SourceKey>TestMove-Dir2/Dir1/Obj1SourceKey> <DestinationKey>TestMove-Dir2-Renamed/Dir1/Obj1DestinationKey> MoveObject> <MoveObject> <SourceKey>TestMove-Dir2/Dir1/Obj2SourceKey> <DestinationKey>TestMove-Dir2-Renamed/Dir1/Obj2DestinationKey> MoveObject> <MoveObject> <SourceKey>TestMove-Dir2/Dir2/SourceKey> <DestinationKey>TestMove-Dir2-Renamed/Dir2/DestinationKey> MoveObject> <MoveObject> <SourceKey>TestMove-Dir2/Dir2/Obj1SourceKey> <DestinationKey>TestMove-Dir2-Renamed/Dir2/Obj1DestinationKey> MoveObject> <MoveObject> <SourceKey>TestMove-Dir2/Dir2/Obj2SourceKey> <DestinationKey>TestMove-Dir2-Renamed/Dir2/Obj2DestinationKey> MoveObject> <MoveCount>7MoveCount> MoveObjectResult>

Composing Objects

myQNAPcloud Object provides a feature to create a new object that is composed of other objects. A composed object is formed not by copying the original data objects, but rather by linking the composed object to the data objects. This is in contrast to AWS S3, which does not offer a way to compose objects. myQNAPcloud Object operation is much faster and does not require multiple copies of the original data. The original composed objects may be deleted at any time, and the system will retain the original data as long as there are any links to the data.

Composing objects is an alternative to using the multi-part upload feature for creating objects larger than 5 GB. The caller must have s3:PutObject policy permission on the bucket to compose objects. Composed objects may be created from other composed objects as well as original data objects. However, the total number of original data objects may not exceed 32 in any one composed object. Composed objects may only link to other objects in the same bucket.

The compose operation is done using the HTTP method PUT with the query string parameter “?compose” to indicate that the object is composed of objects given in the XML body. The XML body contains a list of object keys and, optionally, the version IDs that form the new object. If the version ID is not given, the latest version of the object is used. The new object will appear to be one object with all the linked data objects concatenated. The new composed object does not have an ETag (i.e, MD5) value, which is the MD5 of the concatenated objects, but rather the result of hashing all the data object MD5s together (like the calculation done when multi-part objects are completed). Composed objects may not have user provided encryption keys. However, all data is stored encrypted at rest.

There is a charge only for the metadata used in composed objects. The original data used in linked objects is charged at the normal rate until all composed objects that link to the original data object are deleted.

Below is an example that composes a new object “TestComp from three objects: “TestCompose-Data-1”, “TestCompose-Data-2”, and “TestCompose-Data-3”.

PUT http://s3.wasabisys.com/my_bucket/TestCompose-Object-1?composeHTTP/1.1Content-Type:text/xml
<ComposeRequest>
<Component>
<Key>TestCompose-Data-1</Key>
</Component>
<Component>
<Key>TestCompose-Data-2</Key>
</Component>
<Component>
<Key>TestCompose-Data-3</Key>
</Component>
</ComposeRequest>

Appending to Objects

AWS S3 does not offer a way to append to objects.

Appending to an existing object is a different form of composing an object (see Composing Objects). The call uploads the data in the body to a temporary object and then creates a new composed object consisting of the data from the original object with the newly uploaded data appended. If the bucket is versioned, a new version of the composed object is created while keeping the original data. When not versioned, the newly composed object replaces the original object. The caller must have s3:PutObject policy permission on the bucket to append to objects. Additionally for a bucket without versioning, the s3:DeleteObject policy permission may be required to replace the original object.

Like composed objects, you can append only 1023 times to any object since each creates a link to the uploaded data. Be careful not to simply append small amounts of data many times to an object since each append data uploaded creates a new object subject to minimum size charges, and can slow down the performance due to a small data read. The append operation is done using the HTTP method PUT with the query string parameter “?append”. The data to be appended is uploaded in the body of the request.

Below is an example that appends the string “<appended data>” to an existing object “TestAppend-Object”.

PUT http://s3.us-east-1.myqnapcloud.io/my-bucket/TestAppend-Object?appendHTTP/1.1Content-Length:15

PUT Object Copy Uses Link

Normally, to rename objects using AWS S3 protocol, an object is uploaded with one key value. Then, a PUT operation with the new key value copied from the original key value is given, and the object for the original key value is deleted.

myQNAPcloud Object automatically optimizes this sequence by linking the new key value object to the original data from the copy key value. This avoids making another copy of the data, which would result in higher storage charges. Because myQNAPcloud Object uses links to the original data, any size object up to the 5 TB limit may be copied and does not require the use of a multi-part upload.

Delete Object MFADelete

If the MFADelete option is turned on in the bucket versioning, the “x-amz-mfa” is not required if the access credentials were signed using MFA (see also MFA (Multi-Factor Authentication) Delete).

If bucket logging is enabled, deleting multiple objects will create a separate log entry for each object that is deleted.

GET Object Response Headers

Any header in the GET object request that starts with “response-” will be returned as a response header (minus the string “response-”).

Object Server-Side Encryption

myQNAPcloud Object encrypts all data stored at rest regardless of the requested encryption. The system will use any caller provided encryption keys when given, or generate a random key encryption key for each object if no customer key is provided. If the customer provides the encryption key, similar to AWS S3, myQNAPcloud Object will not keep a copy of the customer key in the metadata and the caller must provide the encryption key to read the data. No action on the part of the caller is needed if myQNAPcloud Object provides the encryption key.

The caller may provide the encryption key using the headers x-amz-server-side-encryption-customer-algorithm, x-amz-server-side-encryption-customer-key, and x-amz-server-side-encryption-customer-key-MD5. These parameters work identical to AWS S3.

myQNAPcloud Object does not support a key management service. Hence, the “x-amz-server-side-encryption” is not supported along with all the “aws:kms” functionality. myQNAPcloud Object stores an MD5 for the data that is always the uploaded data regardless of server-side encryption.

Object Storage Class

myQNAPcloud Object only provides a single storage class which is most like the standard AWS S3 storage class. Where the storage class is returned in any operation, myQNAPcloud Object will return the standard AWS S3 storage class.

Operations on Objects Not Supported in myQNAPcloud Object

The compliance settings for any one object in a bucket with compliance can also be changed within the limits of the compliance on the bucket. Specify the object compliance settings with the following XML tags.

The following is an example of setting the compliance on an object:

PUT http://s3.us-east-1.myqnapcloud.io/my-bucket/my-object?complianceHTTP/1.1
<ObjectComplianceConfiguration>
     <ConditionalHold>false</ConditionalHold>
     <RetentionTime>2018-03-13T10:45:00Z</RetentionTime>
</ObjectComplianceConfiguration>

The compliance settings for any specific object can also be retrieved using the “?compliance” query string. In addition to the object compliance settings above, the query returns the calculated SHA256 hash for the object, which can be used to determine that the object has not been modified. Note that the SHA256 value is only available for objects that are uploaded as a single object and is not available for multi-part or composed objects.

The following is an example of getting the compliance on an object:

GET http://s3.us-east-1.myqnapcloud.io/my-bucket/my-object?complianceHTTP/1.1

Response body:

<ObjectComplianceConfiguration xml ns="http://s3.amazonaws.com/doc/2006-03-01/">
     <RetentionTime>2016-10-31T15:08:05Z</RetentionTime>
     <ConditionalHold>false</ConditionalHold>
     <LegalHold>false</LegalHold>

<SHA256>14b4be3894e92166b508007b6c2e4fb6e88d3d0ad652c76475089a50ebe6e33b</SHA256>
</ObjectComplianceConfiguration>

The object compliance settings also appear in the bucket listings when the bucket has compliance enabled.

You can add or update the object lock settings for an object using the tags described below.

The following is an example of setting the object locking configuration on an object:

PUT https://s3.us-east-1.myqnapcloud.io/qa.objectlock.002/beta_vpn.png?retention&versionId= 001617181245457483475-4ylsTbqqvP

<Retention>
     <Mode>compliance</Mode>
     <RetainUntilDate>2021-04-06T09:00:45Z</RetainUntilDate>
</Retention>

The following is an example of setting legal hold for an object:

PUT https://s3.us-east-1.myqnapcloud.io/qa.objectlock.002/beta_vpn.png?legal-hold&versionId=001617181245457483475-4ylsTbqqvP

<LegalHold>
     <Status>ON</Status>
</LegalHold>

The following is an example of setting governance mode for an object:

PUT https://s3.us-east-1.myqnapcloud.io/qa.objectlock.002/public/ACL.PNG?retention
<Retention>
     <Mode>governance</Mode>
     <RetainUntilDate>2021-05-20T09:00:45Z</RetainUntilDate>
</Retention>

The “x-amz-bypass-governance-retention =true” header must be included whenever you want to override governance settings for an object.

The myQNAPcloud service URLs for myQNAPcloud Object's different storage regions are:

Americas

EMEA

APAC

The myQNAPcloud Object Management Console can be reached through myQNAPcloud Portal.

If you are looking for the correct service URL to use with your third-party storage application, you should choose the one that matches your bucket location.

When working with third-party storage applications, you should be aware that these applications have different methods to handle storage region service URLs. These methods include:

1. Applications that allow you to explicitly enter in the service URL. These applications are the most flexible because you can easily configure new service URLs as they become available.
2. Applications that only allow you to choose from a pre-built list of storage regions. These applications are the least flexible because, if a storage provider implements a new region, you have to wait for an application update to get access to the new region. If your storage application does not support all of the myQNAPcloud Object storage regions on their predefined region lists, contact the application vendor (not QNAP) to ask them for support.
3. Applications that only allow you to enter in your API key set and then offer up all of the buckets in your account. These applications provide flexibility but do require some automatic redirects to perform at the HTTP level.

GET Object Tagging

myQNAPcloud Object supports functionality to fetch the tag set of an object when the object:

• Does not have any tags
• Does have tags

When the Object Does Not Have Any Tags

GET https://s3.myqnapcloud.io/my_bucket/Test-object1.txt?tagging

Response body:

<?xml version="1.0" encoding="UTF-8"?>
<Tagging>
   <TagSet></TagSet>
</Tagging>

Status 200 OK

When the Object Has Tags

GET https://s3.myqnapcloud.io/my_bucket/Test-object2.pdf?tagging

Response body:

<!--?xml version="1.0" encoding="UTF-8"?-->
<Tagging>
   <TagSet>
      <Tag>
         <Key>key2</Key>
         <Value>value2</Value>
      </Tag>
      <Tag>
         <Key>key1</Key>
         <Value>value1</Value>
      </Tag>
   </TagSet>
</Tagging>

PUT Object Tagging

myQNAPcloud Object supports functionality for:

• Adding the tag value of an existing object in a bucket
• Appending the tag value of an existing object in a bucket

Adding the Tag Value of an Existing Object in a Bucket

PUT https://s3.myqnapcloud.io/my_bucket/Test-object3.pdf?tagging
Content-Type: text/xml

Response body:

<Tagging xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
   <TagSet>
      <Tag>
         <Key>tag1</Key>
         <Value>value1</Value>
      </Tag>
   </TagSet>
</Tagging>

Appending the Tag Value of an Existing Object in a Bucket

In this example, an existing object already has the tag value of “key5” –“value5”, You can append a new tag pairs along with the existing pair.

PUT https://s3.myqnapcloud.io/my_bucket/Test-object4.jpg?tagging
Content-Type: text/xml

Response body:

<Tagging xmlns="http://s3.myqnapcloud.io/doc/2006-03-01/">
   <TagSet>
      <Tag>
         <Key>key5</Key>
         <Value>value5</Value>
      </Tag>
      <Tag>
         <Key>key6</Key>
         <Value>value6</Value>
      </Tag>
   </TagSet>
</Tagging>

Status 200 OK

To PUT tags of any other version, use the versionId query parameter.

DELETE Object Tagging

This removes the entire tag set from the specified object.

DELETE https://s3.myqnapcloud.io/my_bucket/Test-object5.pdf?tagging

Response body:

<empty>

Status 204 No Content

To delete tags of any other version, use the versionId query parameter.

Given its compatibility with AWS S3, the official AWS documentation for S3 serves as a complementary resource when working with myQNAPcloud Object. Refer to the Amazon Simple Storage Service API Reference for details on the API version 2006-03-01:

Amazon Simple Storage Service API Reference