0

Draft '/api/drafts/' という名前のリソースと、Revision '/api/revisions/' という名前の別のリソースがあるとします。それらは 1 対 1 の関係で関連付けられています。

リビジョンを作成するには、「/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/revisions/ には副作用があります。ドラフトの属性を変更します。

例）draft.revision_count: 0 => 1

ただし、クライアントはリビジョンの作成を要求し、結果として作成されたリビジョン リソースを受け取るだけであり、ドラフトのデータが変更されたかどうかを知る方法はありません。

私の質問は、リビジョンを作成することによって他のリソースが影響を受け、更新する必要があることをクライアントに知らせる責任があるのはサーバーですか?

4

1 に答える 1

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 は一致せず、クライアントはドラフトの新しい状態を返します。ドラフトのサーバー状態が変化しなかった場合、サーバーは304.

クライアントが知っている状態が現在のサーバーの状態と一致することを確認していない場合、クライアントが下書きを変更しようとすると、競合が発生する可能性がありますPUT。If-None-Matchリクエストにヘッダーが含まれている場合PUT、サーバーは現在のサーバーの状態と古いクライアントの状態の間の不一致を検出できます。適切な HTTP ステータス コードで応答できます。

于 2015-05-13T08:42:21.887 に答える