Jump to: navigation, search

Difference between revisions of "SwiftNextAPI"

(Add PATCH question)
Line 3: Line 3:
  
 
== Version ==
 
== Version ==
 
 
* 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
  - +1 incremental -- Malini
 
  
 
== New Features ==
 
== New Features ==
Line 12: Line 10:
  
 
== Fixes ==
 
== Fixes ==
 
 
* Always quote Etag header value
 
* 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
 
* 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?

Revision as of 12:55, 24 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