当相关资源受到影响时,以RESTful方式响应

时间:2015-05-13 07:58:46

标签: rest http json-api

假设有一个名为Draft'/ api / drafts /'的资源和另一个名为Revision'/ api / revisions /'的资源。它们与一对一的关系有关。

要创建版本,您可以在'/ api / revisions /'上发出请求POST,并在参数中提供草稿ID。 JSON API执行此操作的方式意味着

POST /api/revisions/
Content-type: application/json

{
    "data": {
        "type": "revision",
        "links": {
            "draft": { "linkage": { "id": 1, "type": "draft" } }
        }
    }
}

这会创建Revision资源,它与Draft id = 1相关。所以回复如下:

201 Created
Content-type: application/json
{
    "data": {
        "id": 1,
        "type": "revision",
        "links": {
            "draft": { "linkage": { "id": 1, "type": "draft" } }
        }
    }
}

然而,POST / api / revision /有副作用;它改变了草稿的属性。

例如。)draft.revision_count:0 => 1

但是,所有客户端都提出了创建修订和接收创建的修订资源的请求,因此无法知道草稿的数据是否发生了变化。

我的问题是,服务器是否负责让客户知道通过创建修订版其他资源受到影响并需要更新?

1 个答案:

答案 0 :(得分:0)

服务器不应告知客户在POST /api/revisions的回复中草稿已更改。

但客户不应指望它知道的草案的客户状态仍然有效。它应该提出请求

GET /api/drafts/1
If-None-Match: "etag-of-this-draft-the-server-returned-last-time"

If-None-Match的值将是服务器在先前为此资源所做的响应中返回的ETag。如果草稿的服务器状态已更改,则ETag将不会发生,并且客户端将返回草稿的 new 状态。如果草稿的服务器状态未更改,则服务器将使用304进行响应。

如果客户端不确定它所知道的状态是否与当前服务器状态匹配,则当客户端尝试通过例如对其进行PUT来尝试更改草稿时,可能会发生冲突。如果它在If-None-Match请求中包含PUT标头,则服务器将能够检测当前服务器状态与过期客户端状态之间的任何不匹配。它可以使用正确的HTTP状态代码进行响应。