Json RESTful API场景

我问的是在特定情况下RESTful服务的场景。假设这是一个文件删除服务。用户提交订单，然后在一段时间（1-10分钟）后，一个pdf文件就可以下载了。因此，我提供了一些基本知识：

• 用户使用GET方法向Web服务提交订单（编辑：或发布）
• webservice通过

  json

  或

  xml

  返回一个

  orderid

• 发生一些背景和人为过程（1-10分钟）

• 用户通过将

  orderid

  传递给Web服务来检查订单的状态

• 如果订单已准备就绪，则会向用户返回一个

  statusCode

  和一个

  pdfLink

• 否则，只返回

  状态代码

  （即仍在处理、失败等）

现在，关于这个场景的问题是，用户（其他网站）应该多久尝试获取一个特定订单的状态

我们是否需要建立一个双面Web服务？比如：

• 服务器A向服务器B提交订单
• B通知A订单已准备就绪
• A向B请求

  pdfLink

• A将pdf文件从服务器B传输到A

---

当服务器A向B提交订单时，它还可以指定一个url，如果订单准备就绪，它将在该url上进行调用。这样，服务B不需要知道服务A的细节，它只调用服务A指定的url

服务B给服务A的响应也可能包含一个url，用于下载订单

---

这防止了从服务器A到服务器B的轮询，从而显著降低了服务B的负载。

只是好奇，为什么在请求PDF和实际获取PDF之间有1-10分钟的间隔？首先没有PDF，我们根据订单生成PDF。PDF包含一些可能需要人工审核才能准备好的自定义数据。为什么用户使用GET提交订单？RESTful API将HTTP谓词映射到CRUD方法（创建、读取、更新和删除）。那么你的用户应该发布他们的数据吗？我明白了@格雷厄姆·史密斯也有道理。关于“用户（其他网站）应多久尝试获取一个特定订单的状态”，也许您可以尝试在REST响应中添加类似于

checkAfter

，或

checkEvery

，这样您就可以为客户提出一个行动方案。@GrahamSmith~这是可能的，我只是想问一下这里的概念。但是谢谢你提出这一点。谢谢你的想法，这会很方便的。