データベースへのインターフェースを提供するReSTAPIについて考えてみます。
サーバーは、データベースに存在しない列に新しい値を指定しようとするHTTP 400 Bad RequestonPUTまたはrequestで応答する必要がありますか？PATCHサーバーは黙ってエラーを無視する必要がありますか？サーバーは、ここで言及していない他のことを実行する必要がありますか？
1530 次
4 に答える
2
サーバーが応答
を送信せずに接続を閉じる以外に、とにかくどのようにできるかわかりません。
409 と同様に、400 も適切です。403 Forbidden も検討してください。サーバーはリクエストを理解しましたが、リクエストの実行を拒否しています。
400 は通常、不正な形式のリクエスト用です。
403 は、リクエストが十分に適切な形式であり、サーバー コードがそれを解析してリクエストの目的を理解できた場合に適しています。ここであなたの要件を最もよく満たしていると思います。
しかし、あなたの質問の行は私を心配しています:
データベースに存在しない列に新しい値を指定しようとしています
リクエストでデータベース内の列の値を変更することはできません。リソースのコンテンツを変更する必要があります。2つは同じではありません。「ああ、このドメイン オブジェクトを HTTP リソースとして公開してみよう」という考えに陥りがちですが、それは後でスケーラビリティの問題を引き起こす可能性があります。一般に、モデル オブジェクトよりも多くのリソースを URI 空間に配置する必要があります。これにより、モデルのかなり静的な部分を、より動的な部分とは異なるポリシーでキャッシュできます。
たとえば、注文処理システムでは、配送先住所が変更されることはほとんどありませんが、進行状況トラッカーは数分ごとに変更される場合があります。2 つのデータに異なる URI と異なるキャッシュ ポリシーを指定します。
于 2012-12-04T08:46:28.740 に答える
0
クライアントが余分な値なしで再送信できる場合は、仕様から 409. で応答する必要があります。
10.4.10 409 コンフリクト
リソースの現在の状態と競合するため、要求を完了できませんでした。このコードは、ユーザーが競合を解決してリクエストを再送信できると予想される状況でのみ許可されます。応答本文には、ユーザーが競合の原因を認識するのに十分な情報を含める必要があります。理想的には、応答エンティティには、ユーザーまたはユーザー エージェントが問題を解決するのに十分な情報が含まれます。ただし、それは不可能な場合があり、必須ではありません。
競合は、PUT 要求への応答で発生する可能性が最も高くなります。たとえば、バージョニングが使用されていて、PUT されるエンティティに、以前の (サードパーティの) 要求によって行われた変更と競合するリソースへの変更が含まれていた場合、サーバーは 409 応答を使用して、要求を完了できないことを示す可能性があります。 . この場合、応答エンティティには、応答の Content-Type によって定義された形式で、2 つのバージョン間の相違点のリストが含まれている可能性があります。
于 2012-12-03T22:59:02.760 に答える