Question

有关使用Rest API将表单数据保存到MongoDB的问题。我有三种不同的情况。

保存并返回（第一次部分保存数据，并返回ID以供将来返回）。
提交已经保存的数据（第二次，填写表格并最终提交，以便我可以触发其他工作流程。）
直接提交（第一次提交完整表单并返回ID，然后开始工作流程）

对于上述情况，我想出了以下API资源

POST --> v1/applications   (This will save data and return id)
PUT --> v1/applications/{id} (This will retrieve data using id parameter and update that data)

我的困惑是如何区分这两个API，无论是保存还是最终提交调用，因为我必须在最终提交之后开始工作流程。我可以使用如下所示的一些查询参数来指示提交或保存吗？

POST --> v1/applications?submit=true or false   (This will save data and return id)
PUT --> v1/applications/{id}?submit=true or false (This will retrieve data using id parameter and update that data)

还是我们有更好的方法来区分此api中的保存和提交？

Answer 1

我的困惑是如何区分这两个API，无论是保存还是最终提交调用，因为我必须在最终提交之后开始工作流程。我可以使用如下所示的一些查询参数来指示提交或保存吗？

我认为将信号编码到请求的正文中而不是尝试使用URL来编码会更加普遍。

PUT /applications/12345

Version: 1
Status:  Draft

PUT /applications/12345

Version: 2
Status:  Final

请记住，URI是资源（又称文档）的标识符。做有趣的工作是传递文档的副作用。参见Jim Webber。

如果您正在使用HTML进行所有操作，而HTML本身并不支持PUT，则您可能会使用POST，其中一种形式用于编辑，另一种形式用于定稿，或者可能使用一种形式来处理两种用例

一个问题，因此对于首次保存或第一次直接提交，应使用POST / applications。我说的对吗？

这是常见选择，但不是必需的。真正的区别是-我们是否在目标URL 中创建新资源？

如果是，则PUT，POST，PATCH都是可能的。

如果不是，如果我们正在将请求发送到一个服务器资源，并且期望创建的资源位于其他地方，那么POST是合适的选择。

Answer 2

在RESTFul样式中，查询参数意味着与方案有一些不同，这意味着您无法为使用操作定义规则。在URL中记录功能比在真实文档中记录更好（没有人会仔细阅读...）我认为在您的情况下，最好像这样：

POST v1/applications/add/
PUT  v1/applications/{id}

顺便说一句，一次不能做到完美，良好的服务需要检查和维护。

在Rest API中区分保存和提交

2 个答案: