Difference between revisions of "SwiftNextAPI"
| Line 6: | Line 6: | ||
* incremental update to the current API (1.1) or full new API (2.0) breaking 1.0 compatibility ? | * 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 | - 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) | ||
== Fixes == | == Fixes == | ||
Revision as of 18:49, 23 January 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)
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
