SwiftNextAPI

此页面用于收集关于下一个 Swift API 的想法。

版本

• 增量更新当前 API (1.1) 还是完全新的 API (2.0) 破坏 1.0 兼容性？
  • - 就目前而言，我更倾向于将其作为当前 API 的增量更新。 -- Chuck - +1 增量 -- Malini

新特性

• 加密，以指定所需的算法（或者应该从用户令牌中检索默认算法）

明确的修复

• 始终引用 Etag 头部值
• 根据此 RFC 将速率限制返回码从 498 更改为 429：http://tools.ietf.org/html/rfc6585 另请参阅：https://bugs.launchpad.net/swift/+bug/1099365
• 删除 XML 容器列表中的子目录元素残留的“name”属性。
• ISO 8601 格式的日期不表明时间是 UTC，即末尾应带有“Z”。例如：“2013-03-14T01:46:02.952040Z”。目前，它暗示日期是本地时区。
• 非整数“limit”参数将被忽略；它们应返回 400 响应。（例如：GET /v1/a/c?limit=the-sky）。发生在帐户和容器列表上。
• 统一帐户/容器和对象元数据 POST 语义。在 1.0 中，POST /a[/c] 添加新的元数据，而 POST /a/c/o 替换所有现有元数据。选择一个。（提示：保留当前的容器语义并修复对象语义。替换所有元数据的情况比简单的更新少得多。）
• 修复 HEAD 响应的状态码。根据 HTTP，GET 和 HEAD 的状态码必须匹配。（头部应该匹配，但我们不会这样做，因为它会大大降低速度。）
• 从 204 响应中删除 Content-Length：https://review.openstack.org/291461

有争议的修复

• 使用 PATCH 代替 POST 进行更新操作？
• 添加选项以折叠斜杠，使得 A/B//C///D 将被视为 ('A','B','C','D') 而不是 ('A','B',,'C',,,'D') - 这与 Web 服务器执行的常见 URL 规范化一致，但不符合当前将对象名称视为不透明字符串的做法。