【问题标题】:REST service return collection of XML documentsREST 服务返回 XML 文档的集合
【发布时间】:2019-10-09 19:08:22
【问题描述】:

我们正在编写一个 REST 服务来查询 PDF 文件。服务使用者需要这些 PDF 的元数据,而不是实际的 PDF。的元数据恰好存储为 XML 文档,每个 PDF 资源对应一个 XML 文档。它们的资源和资源的元数据是完全不同的文件。

查询响应应该是什么样的?

通常我们将 JSON 用于请求/响应主体。响应正文是否应该是包含 URL 集合的 JSON 对象,其中每个 URL 链接到元数据文档?这看起来很干净,但会导致很多不必要的网络流量,因为消费者必须为每个元数据文档发送一个 GET 请求。

元数据文档的 XML 是否应该嵌入到响应正文的 JSON 对象中? (糟糕!)

有没有既干净又高效的解决方案?

【问题讨论】:

  • 您所做的所有“REST API”都是为他们提供一个链接以供他们下载 PDF 的元数据,还是这是更大 API 的一部分?
  • 另外,是单个 PDF 的端点,还是带有 GET/POST 参数的单个端点,指定了它们需要元数据的 pdf?
  • @gre GET 资源端点当前获取 1 个 XML 文档。例如。发送 GET 请求“host/metadata/123”将得到一个 XML 文档的响应。
  • 我只是将 XML 文档作为下载返回。它并不是真正的“RESTful API”,它只是一个用于获取文档元数据的 HTTP API。除非您真的愿意,否则您不需要将有效负载嵌套在 JSON/XML 中。
  • 多个,发一个ZIP

标签: rest


【解决方案1】:

基于一些澄清的 cmets,我建议您不要编写“RESTful”API。你不需要一个。您没有需要以任何复杂方式与之交互的对象。您没有需要影响的状态(REST 表示 Representational State Transfer)。

您只需要一个 HTTP API。只需返回 XML 文件。如果需要,您还可以提供一个端点来获取压缩后的多个 XML 文档。

所以做这样的事情:

  • /api/host/123 - 下载 PDF 文件 (Content-Type: application/pdf) - 你没有说你是否已经有一个 PDF 端点,但如果你确实想要一个,这就是我的结构。
  • /api/host/123/metadata - 下载 XML 元数据 (Content-Type: text/xml)
  • /api/host/bulk_metadata - 下载 POST 参数中列出的文件 ID 元数据的 ZIP (Content-Type: application/zip)

使用Content-Disposition: attachment; filename="{filename}.{pdf|xml|zip}" 告诉浏览器将内容下载到磁盘而不是内联显示。

【讨论】:

  • 谢谢格雷格。我很感激。我已经向团队提出了一些选项(包括您的选项)。当我们决定方法时,我会发布更新。
  • @ahoffer 你选了什么?
  • 我在一月份离开了这个项目,我不记得我们做了什么。我认为我们将发送回单个资源的超链接列表并让客户端一个接一个地请求资源。权力决定不会有很多网络流量,因为最终页面大小会限制一次返回的超链接数量。
猜你喜欢
  • 1970-01-01
  • 2018-07-01
  • 1970-01-01
  • 2020-11-04
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多