14

私が構築した RESTFul サーバー API があります。その一部はリソースを制御しておらず、関連する URL + HTTP メソッドをサーバーで実行されるアクションにマッピングするのに問題があります。

たとえば、サーバー上のすべてのリソースを でバックアップできますがPOST /backup、これが最も適切なマッピングかどうかはわかりません。単一のリソースについてはどうでしょうか。私はそれを指定する必要があります:POST /backup/idまたは私が送信する変数として id を宣言することによって:POST /backup <id>

私の API が把握しやすいように、これを最も適切に構成する方法についてのヒントを教えてください。

4

4 に答える 4

7

これは、呼び出すたびにデータベースに新しいバックアップ オブジェクトを作成するか、最後の値のみを保持する多くのバックアップ オブジェクト (たとえば、さまざまなファイルのバックアップ) があるかによって異なります。

POST /backups新しいオブジェクトを作成するために使用されるため、常に新しいバックアップを作成する場合は正しい答えです。

PUT /backups/id同じオブジェクトでバックアップ データを更新している場合。

復路

于 2013-05-23T15:24:03.223 に答える
3

RESTafarians (REST 純粋主義者) は、REST API での唯一のアクションは、HTTP 動詞 ( 、 、および ) をマップする基本的な CRUD 操作であるべきだと言うでしょうが、これGETはPUT実際POST的DELETEではない場合があり、必要以上に仕事を難しくします。なれ。バックアップなどの他のアクションが必要な場合は、HTTP 動詞とリクエスト URL に埋め込まれたアクション名の両方を使用して、実行されるアクションを決定する RPC スタイルの REST 実装を検討することをお勧めします。

GET    /resource/select
GET    /resource/select?id={id}
PUT    /resource/update?id={id}
POST   /resource/insert
DELETE /resource/delete?id={id}
PUT*   /resource/backup?id={id}
GET    /resource/backup?id={id}

*アプリがリソースの複数のバックアップを保持していて、バックアップ アクションで常に新しいバックアップを作成する場合は、通常POST、バックアップはべき等ではないため、これを使用します。バックアップを 1 つだけ維持し、Backup アクションが単にリソースのバックアップをアップサートする場合は、PUT を使用する必要があります。この場合、Backup はべき等であるためです。

于 2013-05-23T15:45:45.777 に答える