Difference between revisions of "Swift/API"
< Swift
(→Middleware) |
(→Features) |
||
Line 83: | Line 83: | ||
* concurrent requests to a resource are allowed, but conflict resolution is done by last-write-wins | * concurrent requests to a resource are allowed, but conflict resolution is done by last-write-wins | ||
* single and multi-range requests are supported | * single and multi-range requests are supported | ||
− | * large objects ( | + | * large objects are supported |
+ | * CORS is not in the 1.0 spec | ||
+ | * versioned writes is not in the 1.0 spec (eg not all deployments enable it) | ||
+ | * expiring objects is not in the 1.0 spec | ||
+ | * path listing support? (notmyname is fine with leaving it out of the spec in favor of only prefix+delimiter) |
Revision as of 18:38, 13 May 2013
Contents
Swift API Definition
Goal: To define the v1.0 API spec for Swift.
We should try to not exclude existing clusters with a v1 definition. Later, after the v1 API is set, then we can discuss changes for v1.1 or v2.
Current v1 API docs
http://docs.openstack.org/api/openstack-object-storage/1.0/content/
Outstanding TODOs
- What do we do about middleware? (see below)
- Implement API versioning and discoverability (see http://lists.openstack.org/pipermail/openstack-dev/2013-May/008436.html)
- Update docs to reflect API changes
Middleware
Middleware | In v1 API | Notes |
---|---|---|
account_quotas | no | [2] |
acl | - | [1] |
bulk | no | [2] |
catch_errors | - | [1] |
cname_lookup | no | [2] |
container_quotas | no | [2] |
crossdomain | no | [2] |
domain_remap | no | [2] |
formpost | no | [2] |
healthcheck | yes | required |
keystoneauth | yes | openstack |
list_endpoints | no | [2] |
memcache | - | [1] |
name_check | no | [2] |
proxy_logging | - | [1] |
ratelimit | no | [2] |
recon | - | [1] |
slo | yes | [2] [4] |
staticweb | no | [2] |
tempauth | - | For testing |
tempurl | no | [2] [3] |
notes
[1] Not part of the external API, therefore NA
[2] Not widely deployed
[3] torgomatic wants this in core since it's been around forever and it's just so damn useful for so many things
[4] notmyname wants this in core because large objects is a key feature of swift
Features
- ACLs are specifically not part of the 1.0 spec
- Auth is not defined in 1.0 beyond "X-Auth-Token is given in each request to authorize the request if the resource is not available publicly"
- "warts" like etags and the differences in setting metadata are defined as they exist today in the code (ie existing clients can't break)
- GET PUT POST DELETE COPY OPTIONS are all supported
- concurrent requests to a resource are allowed, but conflict resolution is done by last-write-wins
- single and multi-range requests are supported
- large objects are supported
- CORS is not in the 1.0 spec
- versioned writes is not in the 1.0 spec (eg not all deployments enable it)
- expiring objects is not in the 1.0 spec
- path listing support? (notmyname is fine with leaving it out of the spec in favor of only prefix+delimiter)