RESTful URIの識別子としてメールを使用しても問題ありませんか？
私はRESTful Webサービスを構築するチームと協力しており、現在の実装では、ユーザーのメールをユーザーリソースの一意の識別子として利用して、次のようなURIを生成しています。
https://www.domain.com/users/[email protected]/resource
メールはシステム内で一意であることが保証されており、ユーザーがメールを変更したときに処理されるため、問題ないようです。しかし、それは正しいですか？議論は、代わりに不変のユーザーIDを使用するかどうかです。この場合、ユーザーIDは次のようになります。
https://www.domain.com/users/a36571b87be464728c8d/resource
または、おそらく何か他に全部。たとえば、いくつかのGoogle APIは単に/users/me/resourceおよび認証データを介してユーザーを識別します。
簡単に言えば、URIで一意であるが可変の識別子を使用することは許容されますか、それとも不変の識別子を使用する必要がありますか？
ありがとう！
あなたの質問には2つのサブ質問があります：
一意ではあるが変更可能な識別子をURLで使用できますか？
これは、IDの変更頻度が低い場合、またはそれらのIDを含むURLがサイト外で使用されていない場合に有効です。 REST APIは通常、特定のURLを後で再利用して同じリソースにアクセスできるという前提で構築されているため、2番目の条件はRESTの概念に少し反します。
これにより、IDが変更される可能性があり、古いIDを使用して行われたリクエストをリダイレクトする意思があるかどうかを判断できます。 （エンコードされた）電子メールアドレスを使用すると、古い電子メールアドレスが別のユーザーによって頻繁に再利用されないため、これはおそらく実現できます。
一意のIDとしてメールアドレスを使用できますか？
@ LucFranken および @ 90 の回答に示されているように、URLにプレーンメールアドレスを使用することはお勧めできませんが、「暗号化」形式のIDとしてのメールアドレス。この「暗号化」は、base64エンコーディングと同じくらい簡単です。
RESTはリソースごとに1つのURLを使用することを好むため、users/meは悪い考えのように感じます。その場合、次のようになります。
users/me users/123myId
同じリソースを指すポイント。ハテオで作業する場合は、自分のリソースへのリンクを提供することをお勧めします。
次に、電子メールについて：私の意見では、URLには機密データやプライベートデータを含めないでください。例：URLは、ロギング、キャッシングなどに使用できます。これにより、1つ以上の電子メールアドレスがリストされる場所が作成されます。
これらは、スパム、ログイン試行などに使用される可能性があります。
参照： https://stackoverflow.com/questions/499591/are-https-urls-encrypted
だから、私はそれをしません。
2016：コメントへの回答：
この時点で、urls/urisについて歩くことに同意します。まったく同じではありません。違いを調べてください。ロイフィールディングについては、以下で何度か触れています。彼はREST https://en.wikipedia.org/wiki/Roy_Fielding およびその他の関連技術の発明者です。
一般に、次のように記述されます。リソースを識別するためのURL。私はそれを次のように捉えています：1つのリソース1つのURLですが、それは難しいルールではありません。
https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_Arch_style.htm パート5.2.1.1はこのトピックで興味深いものです。 「RESTは、代わりに、作成者が、識別される概念の性質に最適なリソース識別子を選択することに依存しています。」自由に選択できるので、同じリソースに複数のURLを選択してみませんか？
この特定のケースの場合：
https://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm#sec_6_2
パート：6.2.5「悪用の1つの形式は、ハイパーメディア応答表現によって参照されるすべてのURI内に現在のユーザーを識別する情報を含めることです。」
幸運にも私は上で見たようにこのケースに対する非常に具体的な答えを見つけました。同じ部分では、発生する可能性のあるキャッシュの問題についても説明しています。
一般的にREST and urls：1つのリソース=== 1 urlであるという証拠は見つかりませんでした。しかし、実際には、私はそれが好きではありません。明確：「ここにそのリソースを見つけることができますが、こことここもここにあります。」HATEOASでは、_selfへのリンクとして何を定義しますか？URLの配列？
W3は、URLの使用に関する興味深い投稿を投稿しました： http://www.w3.org/TR/cooluris/#intro
安定。特定のリソースを識別するためのURIを設定したら、それは可能な限りこの方法のままにしておく必要があります。次の10年について考えてください。たぶん20。 [...]
URLを安定させるための多数の引数を見つけることができるその投稿を読むと、はるかに興味深いものになります。
そして： http://www.w3.org/Provider/Style/URI on「URLが永続的である必要があるとは思いませんでした-それはURNでした。」
しかし、URLは以前の記事で見たようにはるかに広く使用されているので、今度は特にRESTに焦点を当てましょう。
http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
A REST APIは固定リソース名または階層を定義してはなりません（クライアントとサーバーの明らかな結合）。サーバーは独自の名前空間を自由に制御できる必要があります。代わりに、サーバーがクライアントにHTMLフォームやURIテンプレートで行われるような適切なURIを構築するために、メディアタイプとリンク関係内でそれらの指示を定義します。[ここでの失敗は、クライアントがドメインなどの帯域外情報のためにリソース構造を想定していることを意味します-RPCの機能的カップリングと同等のデータ指向の標準である標準]。
したがって、サーバーは使用する適切なURLをクライアントに通知します。サーバーは、URLがどうあるべきかを推測する必要はないと述べています。ハードURLを提供するか、URLテンプレートを提供することによって https://tools.ietf.org/html/rfc657 。したがって、その意味ではそれほど重要ではなく、サーバーがURL構造を変更してもクライアントは引き続き機能します。
また、同じリソースに2つのURLがあるという利点の一部が削除されました。たとえば、/ customers/1と/ user/123/customer/1は、人間が解釈したり変更したりする必要がないためです。
次に、ロイフィールディングによるその投稿のコメントで：
真にRESTfulなAPIはハイパーテキストのように見えます。アドレス指定可能なすべての情報単位には、明示的に（例：linkおよびid属性）または暗黙的に（例：メディアタイプの定義と表現構造から派生）、アドレスが含まれます。
そして：
RESTfulシステムの重要なリソースには識別子が必要です[...]
それは、私にとって、リソースごとに1つのURLを維持するための十分な方向性です。要約すると、厳密なハードルールは見つかりませんでしたが、1つのリソース=== 1つのURLを使用することの意図と利点は、それに固執するのに十分です。複数のURLを使用する利点は、意図していないように手動でURLを作成し始めた場合を除いて、多くは利用できないようです。
より多くの答えのために、あなたはロイ・フィールディング自身にこの質問をするかもしれません。
出会う可能性のあるさまざまな有効な種類の電子メールアドレスを処理する限り、このアイデアは問題ないようです。私はまず、account+purpose@domainのようなメールを日常的に使用しています。 多くのケース があります。
正規化を使用してから、URLエンコードを使用するか、URLで使用する前にメールでbase64を使用することをお勧めします。