用GET请求锁定文件是邪恶的

Question

我试图为Web应用程序实现悲观并发，而我在如何继续锁定文档方面遇到了一些问题。目前，我被告知要锁定文档，它应该是一个POST操作，而不是将文档从GET操作中锁定。

我知道GET方法应该是幂等的，只返回文档而没有任何副作用。我还阅读了有关条件和部分GET的内容，但这似乎没有解决我的问题，因为没有任何头字段似乎可用于悲观并发。

另一方面，POST方法应发送一个文档，服务器应使用该文档来替换现有文档，或者如果服务器上不存在该文档，则创建文档。我发现在POST操作上获取我的文档很困惑。

我对此很困惑。老实说，我不知道如何继续。将来自GET请求的其他读者的文档锁定为副作用。

编辑： 我知道我会因此而被私刑，但即使你感觉不对，我还有其他任何想法。

如果文档被锁定，第一步是使用get请求进行检查。根据该请求的答案，可能会发生三件事。

如果它已解锁，我提交表单以执行POST操作以获取文档。为什么？因此，点击刷新的人不会失去对文档的控制权，并且不会被告知文档被锁定，因为有一个隐藏的令牌可以验证它是否是相同的锁。

如果它被其他用户锁定，我告诉用户它现在无法访问它。

如果用户试图再次打开同一个文档，我需要询问他是否要在该特定选项卡中控制所述文档。如果他这样做，我会得到该文件并创建一个新锁以使前一个失效。

Answer 1

  

是否将GET请求中的其他读者的文档锁定为副作用？

GET是安全方法，不应该用于锁定资源。来自RFC 7231：

  

4.2.1. Safe Methods

     

请求方法被视为＆＃34;安全＆＃34;如果他们定义的语义是   基本上只读;即，客户没有请求，并且确实如此   不要指望，原因服务器上的状态发生了任何变化   将安全方法应用于目标资源。 [...]

可以使用不同的请求来处理

悲观锁定，以检索资源的表示并创建锁。请参阅以下示例。

请求资源的表示：

GET /document/1 HTTP/1.1
Host: example.com

创建一个锁：

POST /document/1/lock HTTP/1.1
Host: example.com

修改资源：

PUT /document/1 HTTP/1.1
Host: example.com
Content-Type: text/plain

This is the new content of the document.

解锁：

DELETE /document/1/lock HTTP/1.1
Host: example.com

尝试修改或检索锁定资源的表示可能会返回409，表示由于与目标资源的当前状态冲突而无法完成请求。服务器还应生成一个有效负载，其中包含足够的信息，供用户识别冲突源。

如果乐观锁定适合您，请考虑conditional requests：

  

条件请求是包含一个或的HTTP请求   更多标题字段，指示之前要测试的前提条件   将方法语义应用于目标资源。 [...]

     

条件GET请求是HTTP的最有效机制   缓存更新。条件也适用于   状态更改方法，例如PUT和DELETE，以防止＆＃34;丢失   更新＆＃34;问题：一个客户不小心覆盖了工作   另一个并行行动的客户。 [...]

查看RFC 7232了解更多详情。