REST APIでインフォーマントと固有の生成ID

Question

RESTful APIを設計する。私はリソース（人のデータ）を識別する2つの方法を持っています。データベースによって生成された一意のID、または各個人用に入力された社会保障番号（SSN）のいずれか。 SSNはおそらくユニークですが、変更することができます。

IDを使用すると、一意であることが保証され、変更されないため、最も便利です。したがって、リソースのURLは、また常に同じまま：

GET /persons/12 

{ 
    "name": Morgan 
    "ssn": "840212-3312" 
} 

引数SSNを使用するため、それがAPIクライアントによって、より有益かつ理解しやすいということです。 SSNは、また、複数のシステムを取り巻くに使用されます。

GET /persons/840212-3321 

{ 
    "name": Morgan 
    "id": "12" 
} 

そこで質問です：私は最初のアプローチで行く、とSSNが変更される可能性があり、いくつかの実装の頭痛を避ける必要があります。そしておそらくSSNからIDに変換するいくつかのヘルパーメソッドを提供しますか？

または、2番目の方法を使用してください。より有益なAPIを提供します。 SSNの変更によりURL：sが変更される可能性があるので、RESTfulでないようなものに対処する必要はありますか？

Answer 1

URLデザインは個人的な選択です。しかし、Rayがすでに提供しているものとは異なるいくつかの例を与えるために、私はあなたに私のものをいくつか与えるでしょう。

私は、ユーザーアカウントのリソースを持っており、両方のURIを介したアクセスを許可する：

/users/12 

と数値がauto_incremented IDをある

/users/morgan 

、およびアルファベット値が上で一意のユーザー名ですユーザーが指定したシステム。これらのリソースはキャッシュ不可能なので、正規化については気にしませんが、 /usersページはアルファベット形式にリンクしています。

私のシステム上の他のリソースには、2つの固有のフィールドがありません。したがって、IDで示されるIDは/jobs/123,/quotations/456です。

「ジョブ123」は「ジョブ」コレクションのものだと思うので、サブリソースを持つ「ジョブ」リソースを持つことは理にかなっているようですそれぞれの仕事。

あなたが検索を実行するための独立した/search/面積を持っている必要はありません、私は直接収集リソースに検索条件を適用するためにきれいだと思う：

/people?ssn=123456-7890 (people with SSN matching/containing "123456-7890") 
/people?name=morgan  (people who's name is/contains "Morgan") 

私は似たものを持っていますが、のみを使用フィルタとして最初の文字：あなたがフィルターとして、または検索条件と考えることができ

/sites?alpha=f 

リストF.で始まるすべてのサイト、これらの用語は同じコインのちょうど異なる側面です。

Answer 2

時間を割いて自分のリソースのURLを考えてみてください！

私は、一人のユーザーにリソースを提供するために一意のIDでUrlを作成します。 Like：

http://api.mysite.com/person/12/ 

ここで、12は固有のIDです。

にかかわらず、URLを返す必要があります....私はまた、単数形「人」を好むことに注意してください：

{ 
    "ssn": "840212-3312" 
    "name": "Morgan" 
    "id": "12" 
} 

しかし、私はまた、一致するユーザーのリストを返す一般的な検索のURLを作成しますパラメータ（json配列または必要な形式）。このようなのparamsを得るのようにして、検索パラメータを指定することができます。

http://api.mysite.com/person/search/?ssn=840212-3312 

それとも

http://api.mysite.com/person/search/?name=Morgan 

これらは、単一の検索ヒットのために、このような何かを返します - それは、配列、ないような単一項目の注意単一のユーザーを直接指し示す一意のID URL。

[{ 
    "ssn": "840212-3312" 
    "name": "Morgan" 
    "id": "12" 
}] 

この検索は、後で他の検索条件のために追加することができます。ユニークなIDの検索URLを返すだけかもしれません - あなたは検索からそれを持っていれば、一意のIDのURLにリクエストをいつでも作ることができます...

Answer 3

どちらも使用しないことをお勧めします。 APIの単一ユーザーと他のすべてのリソース（他のユーザーのリソースを含む）の両方に固有のリソースIDを生成します。

一意のデータベースIDを使用することは、いくつかの理由で理想的ではありません。まず、APIリソースとデータベースレコードが、今日のように設計されていても必ずしも1対1になるわけではありません。次に、異なるフォーマットの固有IDを生成する別のデータストアに変更する可能性があります。

また、SSNなどの他のリソースプロパティからIDを分離することもお勧めします（SSNを非常に安全な方法で保存したいと考えていますが、これは別のトピックです）。何らかの理由でSSNが変更された場合、複数のAPIリソースが同じSSNに関連付けられているか、またはいつかデータが必要でないと判断した場合、IDを変更する必要はありません。

1つのパターンは、リソースタイプを示す数文字で一意のIDを付加することです。たとえば、UserがAPIのリソースタイプである場合、生成される一意のIDはUSR56382のようなものになります。