31

私は RESTful API を実装している最中ですが、変更できないデータが存在する場合の「コミュニティが受け入れる」動作について確信が持てません。たとえば、私の API には、ファイルのバイナリ データやそれに関連付けられたメタデータなど、作成後に変更できない多数のフィールドが作成時に含まれる「ファイル」リソースがあります。さらに、「ファイル」には記述された説明と関連付けられたタグを含めることができます。

私の質問は、これらの「ファイル」リソースの 1 つを更新することに関するものです。特定の「ファイル」を GET すると、ファイルに関連付けられたすべてのメタデータ、説明、タグ、およびファイルのバイナリ データが返されます。特定の「ファイル」リソースの PUT に「読み取り専用」フィールドを含める必要がありますか? 次のいずれかの方法でコーディングできることを認識しています。a) PUT データに読み取り専用フィールドを含めて、元のフィールドと一致することを確認する (またはエラーを発行する)、または b) PUT データ内の読み取り専用フィールドの存在を無視するそれらは変更できないため、ロジックがそれらを無視するため、一致しない場合や欠落している場合でもエラーを発行することはありません。

どちらの方向にも進み、受け入れられるようです。読み取り専用フィールドを無視する 2 番目の方法は、API クライアントが必要に応じてその読み取り専用データの送信をスキップできるため、よりコンパクトにすることができます。彼らが何をしているのかを知っている人にとっては良いようです...

4

2 に答える 2

17

個人的には、どちらの方法も受け入れられます....しかし、私があなたなら、オプション A を選択します (読み取り専用フィールドをチェックして変更されていないことを確認し、そうでない場合はエラーをスローします)。プロジェクトの範囲によっては、Restful WS について消費者が何を深く知っているかを推測することはできません。消費者のほとんどは、たとえ経験豊富であっても、ドキュメントや WADL を読んでいないからです。:)

特定のフィールドが読み取り専用であるというフィードバックをコンシューマーにすぐに提供しない場合、コンシューマーは、Web サービスが行ったすべての変更を再確認せずに処理するという誤った想定をするか、または「一貫性のないフィールド」を見つけると、 」 が更新されると、彼らはあなたの Web サービスにバグがあると他の人に訴えます。

読み取り専用フィールドが元の値と一致しない場合は、2 つの異なる方法でこれにアプローチできます...

  1. リクエストを処理しないでください。409 競合コードと特定のエラー メッセージを送信します。
  2. リクエストを処理し、200 OK と、読み取り専用フィールドに加えられた変更が無視されることを示すメッセージを送信します。
于 2011-02-09T00:45:49.677 に答える
17

読み取り専用データがデータの大部分を占めていない限り (読み取り専用データの送信がネットワーク トラフィックと応答時間に顕著な影響を与えるという極端な場合)、読み取り専用フィールドを受け入れるようにサービスを作成する必要があります。 PUT して変更を確認します。同じデータを出入りさせる方が簡単です。

このように見てください: 読み取り専用フィールドを PUT に含めることをオプションにすることもできますが、サービスにコードを記述して、受信した読み取り専用フィールドに期待される値が含まれていることを確認する必要があります。いずれかの方法で読み取り専用チェックを作成する必要があります。

PUT で読み取り専用フィールドを禁止することは、クライアントが GET で受け取ったフィールドを削除する必要があるため、悪い考えです。これには、クライアントが必要以上にデータやセマンティクスに深く関与する必要があります。クライアントは、これを頭痛の種であり、不必要な合併症であり、負担を増やすための実に意地悪であると考えるでしょう. GET から受信したデータを取得し、関心のある 1 つのフィールドを変更し、PUT でそれを返送することは、クライアントにとって脳死状態の単純な往復であるはずです。必要がないときは、物事を複雑にしないでください。

于 2011-02-09T01:30:17.237 に答える