Difference between revisions of "Swift/API"
m |
(→notes) |
||
| Line 46: | Line 46: | ||
[1] torgomatic wants this in core since it's been around forever and it's just so damn useful for so many things | [1] torgomatic wants this in core since it's been around forever and it's just so damn useful for so many things | ||
| − | [ | + | [2] notmyname: I want this in core because large objects is a key feature of swift, but I realize that it's not widely deployed |
Revision as of 21:08, 28 May 2013
Swift API Definition
Goal: To define the v1.0 API spec for Swift.
Reasons for defining a formal Swift API spec include
- Offer a target for people implementing Swift API compatibility
- Allow client apps to assume a set of functionality across clusters
- Allow changes in Swift that may break existing clients
- Give a better target for doing functional testing against a Swift cluster
Since Swift has never had a formal API spec (ie a document defining the API that the implementation is coded against), we must make allowances for existing clusters. We cannot (or at least IMO should not) define the Swift API v1 in such a way as to exclude existing clusters that are running some previously released version of Swift.
Therefore, this proposal is for the subset of Swift functionality that is A) common to existing clusters and B) a low barrier to entry (but still testable) for any alternate API implementations.
Current v1 API docs
http://docs.openstack.org/api/openstack-object-storage/1.0/content/
Features in Swift v1 API
- 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
- OPTIONS per rfc2616, not with CORS (ie responds with the Allow header)
- concurrent requests to a resource are allowed, but conflict resolution is done by last-write-wins
- multi-range is not supported on large objects
- single and multi-range requests are supported
- CORS is not in the 1.0 spec
- versioned writes is not in the 1.0 spec
- 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)
- Large objects [2]
- dynamic
- static
- bulk requests is not in the 1.0 spec
- signed urls [1]
- formpost is not in the 1.0 spec
- staticweb is not in the 1.0 spec
- quotas is not in the 1.0 spec
notes
[1] torgomatic wants this in core since it's been around forever and it's just so damn useful for so many things
[2] notmyname: I want this in core because large objects is a key feature of swift, but I realize that it's not widely deployed
