REST APIを使用して、クライアントが変更をコミットせずにリクエストを検証するための規則はありますか？
これは、使用例で説明するのが最も簡単な場合があります。
ユーザーがショッピングカートに商品を追加できるeコマースサイトがあるとします。カートに商品を追加するとき、ユーザーは追加したい数量を入力して、[Add]ボタンをクリックできます。 Addをクリックすると、サーバーにリクエストが送信されます。サーバーはまず、現在の在庫に要求された数量を満たすのに十分な数のアイテムがあることを検証します。十分な数のアイテムがある場合は、カートにアイテムを追加して正常な応答を返し、そうでない場合はエラー応答を返します。
ユーザーエクスペリエンスを向上させるために、ユーザーがAddをクリックする前に、ユーザーが入力した数量を検証すると便利です。これには、Addをクリックするとエラーが発生するかどうかをチェックするリクエストをサーバーに送信する必要がありますが、エラーがない場合、カートへの変更はコミットされません。
私の同僚は、この種の機能を必要とするすべてのエンドポイントにクエリパラメータ?intent=validateを追加することを提案しました。追加のエンドポイントを作成する必要がないため、これは良い考えのように思えます。
REST APIがこの種の「検証するが、何もコミットしない」リクエストを処理するための共通の規則はありますか？?intent=validateアプローチは、赤信号を発生させますか？
更新：
フィードバックに感謝しますが、おそらくいくつかのことを明確にする必要があります。
- 私は実際にはeコマースサイトに取り組んでいません。説明しやすい例として使用しました。本当に私はドキュメント管理プラットフォームで働いています。
- ユーザーが100個のドキュメントとフォルダーをフォルダーに移動するなどの一括アクションを要求している可能性があります。ドキュメントやフォルダーに対するユーザーの権限、名前の衝突、フォルダーをそれ自体に移動しないなど、そのような要求に対して検証する必要のある多くのものがあります。したがって、ユーザーが実際にチェックボックスをオンにするたびに検証したい移動するドキュメントのリスト。
- 他のユーザーが同時にアクションを実行しているため、ユーザーが
Submitをクリックして変更をコミットすると、APIは引き続き検証します。重要なのは、ユーザーに早期のフィードバックを提供することです。そのため、コミットする前に2つのドキュメントの名前を変更する必要があることを確認するためだけに100個のボックスをチェックする時間を費やす必要はありません。 - このシステムには、オブジェクトに対するユーザー権限の変更、一括削除、ユーザーグループへの複数のユーザーの割り当てなど、同じ方法で処理する必要のある他の多くの一括リクエストがあります。そのため、各タイプのリクエストがなかった場合は、個別の検証とコミットのエンドポイントが必要です。
REST APIを使用して、クライアントが変更をコミットせずにリクエストを検証するための規約はありますか？
そうではなくて、あなたの言う意味ではありません。 REST識別子に使用しているスペルは関係ありません。RESTでは、URIは不透明です。クライアントは提供されたリンクをたどるだけです。
したがって、データの検証を/c255ed19-d6b0-4666-b9cc-abc48d4246aeに送信し、実際の "do it"リクエストをfbb43bdf-0016-4aa1-9f55-28b884238d40に送信できます。RESTに関する限り、これらのスペルはfine。
したがって、URIにintent=validateパラメータを含めるようにリソース識別子を変更することは問題ありません。代わりに、パスセグメントで別のスペルを使用して意図を区別することにした場合も、問題ありません。 RESTしないcare; URIにエンコードされた意味は、サーバーの裁量で独自に行われます専用。
もちろん、URIのスペルが不透明な場合、そのスペルは有用なセマンティクスを伝えません。 間接の追加レイヤー がどこかにあるはずです。 RESTでは、どこかに link - relation type は、クライアントとサーバーが事前に合意した帯域外情報です。理想的なケースでは、必要な関係はすでに標準化されています。 リンク関係レジストリ をチェックして、必要な情報がそこにあるかどうかを確認できます。そうでない場合は、ビスポーク 拡張関係タイプ を作成して、意味を割り当てることができます。
<link rel="http://example.org/relations/validateOrder" target="/c255ed19-d6b0-4666-b9cc-abc48d4246ae" />
<link rel="http://example.org/relations/placeOrder" target="/fbb43bdf-0016-4aa1-9f55-28b884238d40" />
独自の識別子を作成してこれらの関係を定義するか、既存のスキーマ間の一致を探すことができます
<link rel="http://schema.org/CheckAction" target="/c255ed19-d6b0-4666-b9cc-abc48d4246ae" />
<link rel="http://schema.org/OrderAction" target="/fbb43bdf-0016-4aa1-9f55-28b884238d40" />
GETリクエストの場合は、HEAD動詞が多かれ少なかれ意図されているため（たとえば、サーバーステータスコードを提供する必要があるため）使用できます）POSTあなたはオプションを振ろうとすることができます。
ただし、これらは主にセマンティクスであると思います。特定のユースケースに固有なので、実際には2つの異なるAPIが必要です-/validateおよび/order、両方ともPOSTリクエストを受け取ります。これは意図を最も明確に表現します。
検証メッセージの問題は、すぐに古くなることです。
通常、eコマースサイトは在庫レベルに関係なく注文を受け付けます。常により多くの在庫を注文したり、配送を遅らせたり、最後の手段として謝罪を電子メールで送信したりできるためです。
それを実装する必要がある場合は、別の「在庫レベルのリクエスト」メッセージが表示されます。