OSS相容的S3 API及與S3的差異有哪些 - Object Storage Service

本文介紹OSS相容的S3 API以及OSS與S3的差異。

OSS相容的S3 API

OSS對S3 Bucket、Object以及Multipart操作相容的API如下：

說明

通過標準 S3 協議調用 API 時，x-oss-process參數僅支援image/和style/兩種類型，不支援video/及其他處理類型。

操作類型	API
Bucket操作	PutBucket DeleteBucket GetBucket（ListObjects） GetBucketV2（ListObjectsV2） GetBucketACL GetBucketLifecycle GetBucketLocation GetBucketLogging HeadBucket PutBucketACL PutBucketLifecycle PutBucketLogging
Object操作	DeleteObject DeleteObjects GetObject GetObjectACL HeadObject PostObject PutObject PutObjectCopy PutObjectACL
Multipart操作	InitiateMultipartUpload AbortMultipartUpload CompleteMultipartUpload ListParts UploadPart UploadPartCopy

OSS與S3的差異如下：

請求風格

S3支援路徑（Path）請求風格和虛擬託管（Virtual Hosted）請求風格。路徑風格將Bucket名稱放在URL路徑中，而虛擬託管風格將Bucket名稱作為子網域名稱。基於安全考慮，OSS僅支援虛擬託管訪問方式，即Bucket名稱必須作為子網域名稱使用。因此，在S3遷移至OSS後，用戶端應用和S3工具都需要進行相應設定，確保所有請求採用虛擬託管風格，否則可能導致OSS報錯，並禁止訪問。

ACL許可權定義

OSS對ACL許可權的定義與S3不完全一致，二者的主要區別如下：

層級	許可權	S3	OSS
Bucket	READ	擁有Bucket的list許可權。	對於Bucket下的所有Object，如果某Object沒有設定Object許可權，則該Object可讀。
	WRITE	Bucket下的Object可寫入或覆蓋。	對於Bucket下不存在的Object，可寫入。對於Bucket下存在的Object，如果該Object沒有設定Object許可權，則該Object可被覆蓋。可以初始化分區上傳（InitiateMultipartUpload）。
	READ_ACP	讀取Bucket ACL	讀取Bucket ACL，僅Bucket owner和授權子帳號擁有此許可權。
	WRITE_ACP	設定Bucket ACL。	設定Bucket ACL，僅Bucket owner和授權子帳號擁有此許可權。
Object	READ	Object可讀。	Object可讀。
	WRITE	N/A	Object可以被覆蓋。
	READ_ACP	讀取Object ACL。	讀取Object ACL，僅Bucket owner和授權RAM使用者擁有此許可權。
	WRITE_ACP	設定Object ACL。	設定Object ACL，僅Bucket owner和授權RAM使用者擁有此許可權。

重要

OSS僅支援S3中的私人、公用讀取和公用讀寫三種ACL模式。

儲存類型

OSS與Amazon S3的儲存類型並非一一對應。OSS共有5種儲存類型，S3共有7種主要類型，且在最低儲存時間長度、讀取方式等能力上存在差異。您可根據需要轉換OSS Object的儲存類型。主要對應關係及差異如下：

OSS儲存類型	對應的S3儲存類型	關鍵差異
標準儲存（Standard）	STANDARD	最低儲存時間長度：OSS與S3均無要求。讀取方式：兩者均為即時讀取。
低頻訪問儲存（Infrequent Access）	STANDARD_IA ONEZONE_IA	對應關係：OSS同城冗餘IA對應STANDARD_IA，本地冗餘IA對應ONEZONE_IA。最低儲存時間長度：均為30天。讀取方式：兩者均為即時讀取，有取回費。
Archive Storage（Archive）	GLACIER_IR GLACIER（Flexible）	最低儲存時間長度：OSS為60天，S3為90天。讀取方式：OSS需解凍（約1分鐘），或開啟歸檔直讀實現即時訪問；S3 GLACIER_IR為毫秒級即時讀取，GLACIER（Flexible）需Restore（Expedited 1~5分鐘、Standard 3~5小時、Bulk 5~12小時）。
冷Archive Storage（Cold Archive）	DEEP_ARCHIVE	最低儲存時間長度：均為180天。讀取方式：雙方均需解凍。OSS解凍高優先約1小時、標準2~5小時、批量5~12小時；S3 僅 GLACIER（Flexible）類型達到該解凍時間長度，DEEP_ARCHIVE為Standard ≤12小時（Batch 9~12小時）、Bulk ≤48小時。
深度冷Archive Storage（Deep Cold Archive）	無對應檔	OSS提供的極深冷儲存類型，AWS沒有比DEEP_ARCHIVE更冷的儲存類型（S3無對應檔）。最低儲存時間長度：OSS為180天（S3無對應檔）。讀取方式：OSS需解凍，高優先約12小時、標準約48小時（S3 僅 DEEP_ARCHIVE 類型達到該解凍時間長度）。

說明

此外，S3提供獨立的INTELLIGENT_TIERING（智能分層）儲存類型，可根據訪問頻率在多個訪問層之間自動轉換；OSS沒有獨立的智能階層式存放區類型，需通過生命週期規則實作類別似的自動轉儲。

如果未開啟歸檔直讀，Archive Storage類型的Object在讀取之前，需先使用Restore請求進行解凍。與S3不同，OSS會忽略S3 API的解凍天數設定，解凍狀態預設持續1天，使用者可延長到最多7天，之後Object複歸初始的冷凍狀態。

ETag
- 對於PUT方式上傳的Object，OSS Object的ETag與Amazon S3在大小寫上有區別。OSS為大寫，而S3為小寫。如果用戶端有關於ETag的校正，請忽略大小寫。
- 對於分區上傳的Object，OSS的ETag計算方式與S3不同。