跳转到： 导航, 搜索

Zaqar/specs/api/next

Marconi API - Next

API 改进的头脑风暴页面。以下想法需要与 Marconi 团队和 OS 社区讨论。它们将根据需要转化为蓝图。

通用

摘要 | 日志

  • 如果未提供，自动生成客户端 UUID
    • 这会使事情更加混乱，因为
  • 明确定义每个请求是否需要客户端 ID，并在实现中强制执行
    • 始终需要它，并在每行日志中记录 ID 以进行跟踪、分析、支持等。
    • 计划 v1.1
  • 考虑允许使用不透明字符串作为客户端 ID，而不是 UUID（需要了解其他人想用它做什么？）
    • 生成一个 UUID 并不难
    • 要求使用 UUID 可以简化验证并减少混淆
  • 删除消息发布中已弃用的“部分结果”语义
    • 由于 mongo 驱动程序不再支持此功能，并且其他后端可能也不需要它
    • 简化客户端实现
    • 计划 v1.1
  • 在列出消息和检索单个消息时包含声明信息
    • 在声明数据中包含客户端 ID
    • 在审计队列、诊断时是否有帮助？
    • 以二进制形式存储 UUID（16 字节）时，额外的存储空间微不足道
    • 暂定计划 v1.1 - 需要进一步考虑用例
  • 列出给定队列的声明
    • worker 应该能够信任声明是按预期创建的
    • 其他 worker 不应该查看他们未创建的声明
    • 审计客户端可以列出消息并查看其声明 ID（如果它想验证）
  • 首次向队列发布消息时自动创建队列
    • 重新审视 v2.0
    • 元数据？
    • 创建队列的错误？可以通过操作标志（默认情况下 lazy=True）来缓解
  • 元数据对队列有用吗？

HTTP

摘要 | 日志

  • 返回一个 href，用于使用单个调用删除所有已声明的消息
    • 可能是一种反模式，因为在 worker 崩溃时，先处理多个消息再删除只会增加孤立消息的风险。
    • 如果这是出于性能原因，让我们通过替代传输来解决它（具有小操作负载的持久连接，因此 N 个单独的删除操作非常快）
  • 允许在创建队列时 PUT 元数据
    • 我们将其设为单独的资源，因为稍后我们希望队列资源本身只具有选项，例如默认 TTL（元数据 != 队列属性）
  • 设置队列选项以获取默认值，例如消息和声明 TTL。
    • 客户端可以只实现默认值吗？
    • 虽然需要缓存才能使其快速，但仍然需要一些时间来检查。
  • homedoc 应该返回相对 URI 或在 href-template 中编码版本
  • 204 与 200 + 空数组（例如，在列出消息和队列以及声明消息时）
  • /messages 与 /messages?ids 的响应包的一致性
    • 将其设为不同的资源，以便操作之间的区别更加清晰
    • 计划 v2
  • 响应包通常 - 不要返回原始数组（以便允许扩展）
    • [] ===> {"things":[]}
    • 计划 v1.1
    • 问：这是否也适用于请求体，即发布消息？
  • 在 location/content-location 标头中返回完整的 URI（而不是相对 URI）
    • Repose（目前）不支持标头中的部分 URI - 它尝试解析它们而不是直接传递它们
    • 客户端没有任何问题，并且其他 rproxies 似乎也不在意。
  • content-location 标头真的有必要吗？
    • 它只有在您拥有可以使用不同路径访问的资源的替代表示形式时才有用，而不是在 Accept 中指定媒体类型时。
    • 不再设置此标头 - 节省一些字节的带宽，并且它没有用
    • 计划 v1.1
  • 轮询模型基于“流式”交互模型的假设。是否有“时间点”列出模型，您不必总是获得“下一个”href？
    • 在计划 v2 时重新审视
  • 查询参数通常被认为是“可选的”，但 DELETE queues/my-queue/messages 需要一个“ids”参数。一些选项
    • 保持原样。看看是否有人抱怨。
    • 使“ids”可选。在这种情况下，DELETE my-queue/messages 将被定义为删除队列中的所有消息。另请参见：https://blueprints.launchpad.net/marconi/+spec/flush-queue
    • 允许在路径中使用 id 列表，例如 my-queue/messages/1,2,3。我们曾在早期的 API 草案中尝试过此方法，但很多人认为它看起来很奇怪/不寻常，所以我们没有这样做。
    • 创建一个单独的资源 - 可能是与用于 GET messages?ids=1,2,3 的资源相同
    • 不支持对消息进行批量 DELETE 操作。
    • 在计划 v2 时重新审视
  • 发布消息的响应中使用的资源是否应该使用相对路径而不是绝对路径？
    • 是的，计划 v1.1
    • 在某些情况下，考虑返回 404 而不是 403，如果可以减少泄露可能用于攻击的信息
从 "https://wiki.openstack.org/w/index.php?title=Zaqar/specs/api/next&oldid=60004" 检索