gpt4 book ai didi

design-patterns - 持久的 RESTful 交互

转载 作者:行者123 更新时间:2023-12-01 07:33:02 24 4
gpt4 key购买 nike

目前我们的团队正在讨论,我对其他观点很感兴趣。假设我们有一个 RESTful Web 服务,其作用是通过应用各种分析算法和服务来注释文档。明确的基本交互:我们有一个资源,即文档集合;客户端向集合发布一个新文档,取回新文档的 URI,然后可以获取 docURI取回文件或获取 {docURI}/metadata查看一般元数据,{docURI}/ne对于命名实体等。问题是某些分析可能需要很长时间才能完成。假设客户端在分析完成之前获取元数据 URI,因为它希望能够在 UI 中显示部分或增量结果。将来重复 GET 可能会产生更多结果。

我们讨论过的解决方案包括:

  • 保持 HTTP 连接打开
    直到所有分析完成(其中
    似乎不可扩展)
  • 使用content-lengthaccept-range标题以获取增量内容(但
    我们不知道提前多久
    最终内容将是)
  • 提供
    每个资源的 Atom 提要
    客户端订阅更新
    事件而不是简单的 GET
    资源(似乎过度
    如果有许多事件文档,则复杂且可能资源匮乏)
  • 只需 GET 返回
    任何当时可用的东西(但它仍然
    留下客户的问题
    知道我们什么时候终于完成了)[编辑以删除评论后对幂等性的引用]。

  • 对于在 RESTful 架构中处理长期或异步交互的替代方法有任何意见或建议吗?

    伊恩

    最佳答案

    我将通过以下方式实现它:

    1) 客户端请求元数据
    2) 服务器返回实际数据(如果它已经可用)或 NotReady 标记
    3) 客户端询问服务器数据何时可用(此步骤可与上一步合并)
    4)服务器返回时间间隔(可能对执行作业的总数等有一些启发)
    5) 客户端等待指定的时间并转到步骤 1

    这样您就可以尽快向客户提供数据。您可以通过调整步骤 4 中返回的延迟间隔来调整服务器负载)

    关于design-patterns - 持久的 RESTful 交互,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/120158/

    24 4 0
    Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
    广告合作:1813099741@qq.com 6ren.com