web-dev-qa-db-ja.com

メールが一意かどうかを確認するRESTfulサービス

ユーザーのメールが一意かどうかを確認できるエンドポイントが必要です。この操作は信じられないほどRESTfulに見えないため、どのように適合させるかを理解するのに苦労しています。これを、次のようなRPCスタイルのエンドポイントにすべきかどうかについて議論してきました。

[〜＃〜] url [〜＃〜]

GET identities/check_email

応答

{
  "ok": false,
  "error": "taken"
}

これが問題であるということは、私たちが行っている他のすべてのことと信じられないほどうまく適合しません。

HEADリクエストを送信することも検討しましたが、どのようになるかはよくわかりません。

restapiapi-design
4
anthonator

HEAD動詞を使用します。 GET /identities/[email protected]がJoeに関するJSONを含む200 Okayまたは404 Not Foundを返す場合、HEAD /identities/[email protected]はGETと同じように機能しますが、ヘッダーとステータスコードのみを返します。 HEADを任意のリソースの「存在チェック」として使用できます（リソースをホストしているサーバーがHEAD動詞を正しく理解していると想定しています）。

これは、個々のユーザーがリソースであり、電子メールで識別可能であると想定しています。現在、/identities/123などのIDによるユーザーの識別のみをサポートしている場合、/identities/emails/{email}を返すか、一致するユーザーのURLにリダイレクトする404 Not Foundルートを追加できます。

5
Jack

RESTの最初の2つのルールは、すべてがリソースであり、考慮すべき唯一の動詞はHTTPが指定する動詞であることです。

私は実際に外に出て、IDへのアクセスが/identitiesで始まるモデルがあり、GET /identities/1234を使用してIDでそれを引き出すことができると仮定します。また、APIがJSONを出力し、URIの先頭のhttp://Host/が簡潔さのために暗示されていると仮定します。

理論的には、GET /identitiesを実行して、システム内のすべてのIDへの参照を含む配列を取得できます。

[ "/identities/1234", "/identities/5678", "/identities/9012", ... ]

それはおそらく望んでいないことですが、クエリ文字列を使用してリストをサブセットに制限することで、少量で許可することができます。 GET /[email protected]は、ビジネスルールで一意である必要があると記載されているため、メールアドレスが存在するかどうかを確認するための理想的なフィルターです。つまり、返される配列は常に0または1つの要素になります。

GET /[email protected]
[ "identities/1234" ]

GET /[email protected]
[]

これに対処する別の方法は、同じリソースへの複数のパスがあるモデルにフィルタリングを組み込むことです。

/identities/by-id/1234
/identities/by-email/[email protected]

2番目のリソースを取得しようとすると、200のメールアドレスを持つ識別子が存在する場合は[email protected]が返され、存在しない場合は404が返されます。 RESTインターフェースでは同じリソースへの複数のパスを持つことは許容できると見なされますが、2つの同一でないURIが同じリソースを指しているかどうかがわからないなど、論理的な問題があるかどうかを考慮する必要があります。

1
Blrfl