SwiftNextAPI

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)

Undisputed Fixes

 * Always quote Etag header value
 * 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
 * Remove vestigial "name" attribute of subdir elements in XML container listing.
 * Dates represented in ISO 8601 do not tell you that the time is in UTC, i.e., there should be a "Z" at end. Example: "2013-03-14T01:46:02.952040Z". As-is, it implies the dates are in local timezone.
 * Non-integer "limit" params are ignored; they should result in 400 responses. (Example: GET /v1/a/c?limit=the-sky). Happens for account and container listings.
 * 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. (Hint: keep the current container semantics and fix object semantics. Replace-all-metadata is much less common than a simple update.)
 * Fix status codes for HEAD responses. According to HTTP, the status code for GET and HEAD MUST match. (The headers SHOULD match, but we're not going to because it would slow things down a whole lot.)
 * Remove Content-Length from 204 https://review.openstack.org/291461

Disputed Fixes

 * Use PATCH instead of POST for updating operations?
 * Add option to collapse slashes such that A/B//C///D will be treated as ('A','B','C','D') and not as ('A','B',,'C',,'','D') - this is inline with the common URL normalization performed by web servers and not inline with the current practice of treating object names as opaque strings.