跳转到： 导航, 搜索

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" 检索