2

クライアントが HTTP PUT リクエストで送信して親オブジェクトを更新できる次のオブジェクト グラフがあるとします。

{
  "Id": 123,
  "FirstName": "Joe",
  "LastName": "Smith",
  "Schools": [
    {
      "Id": 444,
      "Name": "Fun University"
    },
    {
      "Id": 555,
      "Name": "Unfun University"
    }
  ]
}

私のサービスでは、学校を更新する唯一の方法は Student を使用することです。ただし、クライアントが「444」IDを変更するのを必ずしも防ぐことはできません。

私の質問は次のとおりです。1. ID 444 の学校が ID 123 の学生に属していることをサーバーで検証するだけで安全ですか? 2. または、クライアントは、学生サービスを使用して学生にリクエストを送信し、学生サービスの学校のリストを使用して、学校サービス (私が作成する) を呼び出し、そこで PUT を実行する必要がありますか?

シナリオ 1 では、http://www.mydomain.com/api/students/123 (PUT) を使用してオブジェクト全体を更新します。

シナリオ 2 では、http://www.mydomain.com/api/schools/444 (PUT)を使用して学校オブジェクトのみを更新します。

今のところ、私の意図はアプローチ＃1ですが、これは良いアプローチではありませんか？

4

1 に答える 1

2

それは十分に安全ですか...

ID 444 の学校が ID 123 の学生に属していることをサーバーで検証するだけです。

なぜ依存関係をチェックするのですか？
学校を編集するだけなら、生徒のリソースには何の関心も持たないはずです。

あなたPUT /student/123/school/444を発行して処理するだけです。顧客がより直接的なアクセスを持つことが理にかなっている場合は/school/{ID}、新しいサービスとして実装するだけです.

本当に必要なのはID-not-changeable constraint. ユーザーが put リクエストを介してリソースの ID を変更することを禁止するだけです。ID の変更が必要になることはめったになく、影響があるため慎重に処理する必要があります (すべての生徒の関係を更新する必要があります)。

APUT /students/123は、学校自体を変更することを許可されるべきではなく、生徒と学校との関係のみを変更することを許可する必要があります (生徒から学校を削除するか、新しい追加を追加します)。
これを処理するコードはすべてあなた次第です。

于 2013-03-28T15:09:42.993 に答える