RESTful APIでリソースの存在を確認するための適切なルート
リソースの存在を確認するためのAPIエンドポイントを設計するための最良の/安らかな方法は何ですか？
たとえば、ユーザーデータベースがあります。新規ユーザーがサインアップを試みている間に、メールがオンザフライで使用されたかどうかを確認したいと思います。
私の考えは：POST /user/existsで、ペイロードは{"email": "[email protected]"}のようになります。応答は、200 OKまたは409 Conflictのいずれかになります。
これは正しい方法ですか？
ありがとう！
HEADは、存在チェックに最も効率的です。
HEAD /users/{username}
ユーザーのパスをリクエストし、存在する場合は200を、存在しない場合は404を返します。
心に留めておいてください。おそらく、メールアドレスをチェックするエンドポイントを公開したくないでしょう。セキュリティとプライバシーの穴が開きます。 redditのように、サイトの周りにすでに一般公開されているユーザー名は問題ないかもしれません。
存在を確認する適切な方法は、HEADリクエストで通常取得するリソースにGET動詞を使用することだと思います。
最近、サーバー上に潜在的に大きいビデオファイルの存在を確認したいという状況に遭遇しました。サーバーがバイトをストリーミングしてクライアントに送信したくないので、HEADリクエストを実行したときにクライアントが受け取るヘッダーを返すGETレスポンスを実装しましたビデオ。
HEAD動詞の実際の使用法については、W3仕様 ここ を確認するか、または このブログ投稿 を参照してください。
リソースの存在を確認するために、通常のRESTfulルートとは異なる方法でルートを形成する方法を考える必要がないため、これは素晴らしいと思います。何か。
GET /[email protected]
これは基本的な検索クエリです。メールアドレスが指定されているユーザーを検索してください。ユーザーが存在しない場合は空のコレクションで応答するか、条件に一致するユーザーで応答します。
私は好む：
HEAD /users/email/[email protected]
説明：電子メール[email protected]を使用しているユーザーをすべてのユーザーから見つけようとしています。ここでは、電子メールがリソースのキーではなくであり、ある程度の柔軟性があると仮定しています。別のエンドポイントが必要な場合は、ユーザー、このアプローチは非常によく適合します。
応答として、httpコード応答として200（使用できない場合）または404（使用可能な場合）のみを返します。
次のものも使用できます。
HEAD /emails/[email protected]
HEAD /users/email/[email protected]が既存のRESTリソースと競合する場合（異なるビジネスルールのGET /users/email/[email protected]など）。 Mozillaのドキュメント で説明されているように：
HEADメソッドは、GETリクエストと同じレスポンスを要求しますが、レスポンスボディはありません。*。
したがって、異なるルールを持つGETとHEADを使用するのはよくありません。
あなたが（おそらく）HEAD /users/[email protected]を持っているので、電子メールがusersの「キー」である場合、GET /users/[email protected]も良いオプションです。