Difference between revisions of "SwiftNextAPI"
(Add PATCH question) |
|||
| Line 8: | Line 8: | ||
== New Features == | == New Features == | ||
* encryption, to specify desired, algorithm (or should it be a default retrieved from the user token) | * encryption, to specify desired, algorithm (or should it be a default retrieved from the user token) | ||
| + | * Unify account/container and object metadata POST semantics. In 1.0, POST /a[/c] adds new metadata, while POST /a/c/o replaces all existing metadata. Pick one. | ||
== Fixes == | == Fixes == | ||
Revision as of 19:02, 6 February 2013
This page is here to collect ideas for the next Swift API.
Version
- incremental update to the current API (1.1) or full new API (2.0) breaking 1.0 compatibility ?
- - For the purposes of this, I would prefer to keep it as an incremental update to the current API. -- Chuck - +1 incremental -- Malini
New Features
- encryption, to specify desired, algorithm (or should it be a default retrieved from the user token)
- Unify account/container and object metadata POST semantics. In 1.0, POST /a[/c] adds new metadata, while POST /a/c/o replaces all existing metadata. Pick one.
Fixes
- Always quote Etag header value
- Possibly change rate-limiting return code from 498 to 429 as per this rfc: http://tools.ietf.org/html/rfc6585 also see: https://bugs.launchpad.net/swift/+bug/1099365
- Use PATCH instead of POST for updating operations?
