Jump to: navigation, search

SwiftNextAPI

Revision as of 17:01, 6 December 2013 by Samuel Merritt (talk | contribs)

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?
  • 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.
  • 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.