包含 POST 和 PUT/PATCH 的 REST API 调用计算服务器生成结果文件

Question

我正在实现的服务器应用程序生成计算结果并将这些结果文件存储在服务器目录中的结果文件中。例如，客户/项目/方案/结果文件。我想设计和实现一个有弹性的 REST 实现来检索结果文件以在客户端浏览器中显示，删除结果文件、客户等，并在场景中创建结果文件以用于发送到服务器的计算参数。并且可能通过改变计算参数进行敏感性分析以在场景中生成结果文件。

我可以使用 GET 使用带有查询字符串 appname/?customerId=xxx&projectId=xxx 等的 URL 检索这些文件，并使用查询字符串删除目录结构和文件。我不清楚的是调用在服务器上实现各种计算的函数的最佳 REST 方法。

也许这应该是场景中初始计算的 POST，因为它正在创建结果文件？可能是用于敏感性分析或其他部分重新计算的 PUT 或 PATCH，因为这会修改现有场景中的结果？

关于用于数据库相关活动的 PUT、PATCH 和 POST 的在线讨论相当多。我可以根据我所阅读的 REST 数据库交互内容制定一种 REST 方法，但如果已经有关于如何通过 REST API 进行计算的标准做法，我宁愿使用它。

Answer 1

也许这应该是场景中初始计算的 POST，因为它正在创建结果文件？可能是用于敏感性分析或其他部分重新计算的 PUT 或 PATCH，因为这会修改现有场景中的结果？

您可以始终只使用 POST。如果我们使用资源的 HTML 表示来引导客户端通过协议，我们将通过跟踪链接和提交表单来做到这一点。在 HTML 中，提交表单仅限于 GET 和 POST。

PUT 和 PATCH 比 POST 具有更严格的语义约束。具体来说，它们是请求服务器使其表示与客户端表示匹配的方法（对于 PUT，我们发送整个替换表示；对于 PATCH，我们只发送客户端所做的更改）。

从技术上讲，服务器不接受所提供的编辑并没有什么问题：

给定表示的成功 PUT 将表明对同一目标资源的后续 GET 将导致在 200（OK）响应中发送等效表示。但是，不能保证这样的状态变化是可观察到的，因为在接收到任何后续 GET 之前，目标资源可能会被其他用户代理并行操作，或者可能会受到源服务器的动态处理。成功的响应仅意味着用户代理的意图在源服务器处理时已实现。

因此服务器可以接受客户端的编辑，然后立即应用自己的其他编辑。