要求を行う前にREST APIラッパーが入力を検証する必要がありますか？

Question

サーバーがJSONフィールドを列挙された値のセットに制限しているとします。

/userへのPOST要求では、 "male"、 "female"または "n/a"のみであるgenderというフィールドを持つオブジェクトが必要です。

要求を行う前に、ラッパーライブラリでフィールドが正しく設定されていることを確認する必要がありますか？

Answer 1

Pro：クライアントがサーバーへのラウンドトリップを必要とする入力をすぐに拒否することを可能にします。場合によっては、これはずっと優れたUXを可能にします。

Con：libaryをバックエンドと同期させておく必要があります。そうしないと、有効な入力が拒否される可能性があります。

適切なタイプのシステムでは、この特定の制限をライブラリAPIにエンコードする必要があります。私は通常、クライアントで少なくとも基本的なものを検証し、クライアントでは検証できないような検証をサーバーに実行させると思っています。

Answer 2

これは設計上の選択です。列挙型の制約は、サーバーのパブリックAPIで文書化する必要があり、契約の一部です。

クライアントは、要求を成功させるために契約に従うことを余儀なくされますが、検証ロジックを実装する必要はありません。 「Bad Request」やその他の4xxエラーが発生しても、クライアントが失敗することはありません。

検証ロジックを両側に実装すると、クライアントとサーバーが結合されます。検証ロジックの変更は、両方の側で実装する必要があります。 検証ロジックが常識に近いものであれば（このフィールドは空であってはいけません）、両側で安全に実装できます。 検証ロジックがより特定のドメイン固有のものである場合、私はそれがバックエンド側にのみ保持されるべきだと思います。

ラッピングライブラリ（サーバーAPIのクライアントとして見なすことができます）で同じトレードオフについて考える必要があります。ラッピングライブラリの役割は - ラッピングライブラリがサーバーの完全なAPI契約を公開する必要がある場合 - つまり、検証ロジックをラッピングライブラリに複製することができるかどうかによって異なります - それ以外の場合はバックエンドに保管します。

Answer 3

wrapper-libraryはREST APIの実際のクライアントであるため、architecturalとプロトコル強制制約の両方を遵守する必要があります。 his blog postでは、Fieldingは制約のいくつかをさらに説明しました。そのうちの1つはtyped resourcesです。クライアントはAPIが特定のタイプ、つまりJSON内のいくつかのユーザーの詳細を返すと想定してはいけないと述べています。これは、メディアタイプとコンテンツネゴシエーションが実際に行うものです。

メディアタイプの定義は、クライアントに、JSONまたはXMLのvCardフォーマットのように、受信したデータの処理方法に関するヒントを与える場合があります。メディアタイプは、特定のドキュメントの実際のフォーマットを定義するので、事前検証要件や構文規則などの処理ルール、すなわちXMLスキーマまたはJSON schema検証を含むことができる。

リモートコンピューティングの基本的なルールの1つは、受信した入力を信頼できないため、サーバーはクライアントが以前に事前検証を行ったかどうかにかかわらず結果を検証する必要があります。型指定されたリソース制約のため、真のRESTfulクライアントは、受信したメディアタイプが仕様を通じて事前検証をサポートしているかどうかをチェックし、仕様がそれを定義している場合にのみ事前検証を適用し、特定のスキーマメカニズム）。

私の個人的な意見は、RESTアーキテクチャーのアプローチに従うと、メディアタイプが明示的にそれをサポートしていない限り、入力を検証してはいけないということです。クライアントはエラーレスポンスを通じて、特定のRESTエンドポイントが期待するフィールドと値を知り、サーバーはうまくいけば入力を検証しますが、クライアント側で検証する必要はありません。パフォーマンスの考慮事項は、ルールや推奨事項を守ることよりも重要な場合が多いため、あなた次第です。ただし、これはクライアントをサーバーに接続する場合と接続しない場合があるため、サーバーの変更をより簡単に破る危険性が高くなります。 RESTはプロトコルではなく設計上の提案であるため、どのルートを使用するかはあなた次第です。