De facto standards for the storage layer, published by the API Commons.
Nobody ratified S3 as the object-storage standard. It became one because vendor after vendor implemented Amazon's interface on their own hardware, and an application written against one now runs against dozens by changing an endpoint.
This repository writes that interface down. It is also the profile in this programme with the WEAKEST evidence behind its adoption numbers, and saying so plainly is part of the work.
| Operation | Route | Declaring | Share |
|---|---|---|---|
ListBuckets |
GET / |
10 | 83.3% |
ListObjects |
GET /{Bucket} |
10 | 83.3% |
DeleteBucket |
DELETE /{Bucket} |
9 | 75.0% |
DeleteObject |
DELETE /{Bucket}/{Key+} |
9 | 75.0% |
GetObject |
GET /{Bucket}/{Key+} |
9 | 75.0% |
CreateBucket |
PUT /{Bucket} |
8 | 66.7% |
HeadObject |
HEAD /{Bucket}/{Key+} |
7 | 58.3% |
PutObject |
PUT /{Bucket}/{Key+} |
7 | 58.3% |
Eight operations — the CRUD primitives and nothing else. Multipart upload does not reach core, which for an object-storage standard is surprising until you look at the cohort.
| Extended | Declaring | Share |
|---|---|---|
CreateMultipartUpload |
5 | 41.7% |
HeadBucket |
5 | 41.7% |
CopyObject |
4 | 33.3% |
AbortMultipartUpload |
3 | 25.0% |
ListMultipartUploads |
3 | 25.0% |
UploadPart |
3 | 25.0% |
CompleteMultipartUpload |
2 | 16.7% |
ListObjectsV2 |
2 | 16.7% |
One result worth pausing on: ListObjects — the version AWS has recommended against for
years — is declared by 83.3% of the cohort, while ListObjectsV2 reaches 16.7%. What
the ecosystem implements and what the originator recommends are different things, which
is the entire premise of profiling a standard from practice.
58 providers claim S3 compatibility. 12 publish an OpenAPI that declares an S3 operation. That is the denominator here, and it is the thinnest of the five standards in this programme — every share above should be read as a signal rather than a census.
There is no tested grade here, and that was tested rather than assumed.
An S3 server validates the signature before it routes the operation, so an
unauthenticated caller cannot tell a supported operation from an unsupported one. Tested
on 2026-09-13: MinIO's public endpoint answers AccessDenied to both ?list-type=2 and
?accelerate, and AWS returns 307 to everything. There is no anonymous discriminator, so
the tested grade that carried the blockchain and open-data profiles is unavailable.
Several providers publish good compatibility matrices, which would be the natural evidence here. MinIO's and Backblaze's render client-side and serve no operation names in their HTML; Cloudflare R2's names 73 operations but does not mark support in any parseable structure. Rather than guess which half of a list is supported, R2 and MinIO are recorded as vendor-matrix claims with their URLs, and no per-operation support is synthesised from them.
Evidence across 46 registry entries: 12 declared, 2 vendor-matrix, 32 prose.
99 of 116 operations are distinguished by a query subresource, and the whole API collapses to 12 distinct method and path pairs. A path map keeps one operation per pair and loses 104 of them.
So s3-model.json is the artifact of record — a tier-stamped derivative of botocore's
model, which can express an operation identified by a subresource. openapi.yml is a
labelled convenience: each method and path pair keeps one operation and lists every
operation on that pair in x-s3-operations with its own tier.
The core tier happens to be exactly the part of S3 that OpenAPI CAN express — all eight core operations are base operations on distinct method and path pairs — which is why the Spectral ruleset works at all.
| Method and path | Operations sharing it |
|---|---|
GET /{Bucket} |
36 |
PUT /{Bucket} |
27 |
DELETE /{Bucket} |
16 |
PUT /{Bucket}/{Key+} |
11 |
GET /{Bucket}/{Key+} |
10 |
DELETE /{Bucket}/{Key+} |
4 |
standard/s3-2006-03-01/
profile.yml 116 operations, each with its tier and the evidence
s3-model.json the artifact of record — tier-stamped, subresources intact
openapi.yml a labelled convenience, collapsed to the method and path pairs
schema/ JSON Schema 2020-12 for each core operation's input and output
mcp/tools.json MCP tool definitions for the core tier
arazzo/ create, put, get, list, delete, delete — the flow needs credentials
spectral/ generated from the profile, with fixtures and a harness
adopters/
s3-2006-03-01.yml 46 entries
s3-2006-03-01-matrix.md operation by provider
scripts/ every artifact above is generated; none is hand-maintained
npx @stoplight/spectral-cli lint their-openapi.yaml \
-r https://raw.githubusercontent.com/api-commons/storage/main/standard/s3-2006-03-01/spectral/s3-profile.yaml
It checks the core tier and warns on a document that declares JSON-only responses, because S3 is rest-xml. It cannot check the subresource operations, request signing, addressing style or region behaviour — all real compatibility questions, none of them visible in a path.
Derived from boto/botocore —
botocore/data/s3/2006-03-01/service-2.json at commit
aeb03fc4ae530e0b3f47d588b6021581db870c8c. 116 operations, 722 shapes, protocol rest- xml, API version 2006-03-01. That repository is Apache-2.0; this profile carries
its NOTICE and does not republish it.
Not published by, affiliated with, or endorsed by Amazon Web Services. The name S3 appears here as a factual reference to the interface being described.
Related
- adopters — the schema behind the registry
- models · blockchain · open-data
Artifacts are CC BY-NC-SA 4.0. Code in scripts/ is
Apache-2.0.