14

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

IDは一意であることが保証されており、変更されないため、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が変更される可能性がある、それほどRESTfulではない奇妙な問題に対処する必要がありますか？

4

4 に答える 4

9

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

ユーザーアカウントリソースがあり、両方のURIを介したアクセスを許可しています。

/users/12

と

/users/morgan

ここで、数値はauto_incremented IDであり、アルファベット値はユーザーが指定したシステム上の一意のユーザー名です。これらのリソースは入手できないので、正規化については気にしませんが、/usersページはアルファベット形式にリンクしています。

私のシステムの他のリソースには2つの固有のフィールドがないため、ID 、、によって参照され/jobs/123ます/quotations/456。

ご覧のとおり、私は複数のURIセグメントを好みます;-)
「job123」は「jobs」コレクションからのものであると考えているので、各ジョブのサブリソースを持つ「jobs」リソースを持つのは論理的です。

検索を実行するために別の領域を用意する必要はありません/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で始まるすべてのサイトを一覧表示します。これはフィルター、または検索条件と考えることができます。これらの用語は、同じコインの異なる面にすぎません。

于 2013-02-11T16:26:11.890 に答える
3

誰かが自分のリソースURLについて考えるのに時間をかけているのを見るのは良いことです！

単一のユーザーにリソースを提供するために、一意のIDを使用してURLを作成します。好き：

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

ここで、12は一意のIDです。私も単数の「人」を好むことに注意してください...。

とにかく、URLは次のように返されます。

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

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

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

または

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

これらは、単一の検索ヒットに対してこのようなものを返します。これは配列であり、単一のユーザーを直接指す一意のIDURLのような単一のアイテムではないことに注意してください。

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

この検索は、後で他の検索条件に拡張できます。検索URLを介してのみ一意のIDを返す場合があります。検索から取得した一意のIDURLに対して、いつでもリクエストを行うことができます...

于 2013-02-11T15:44:28.743 に答える
1

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

一意のデータベースIDを使用することは、いくつかの理由で理想的ではありません。まず、APIリソースとデータベースレコードは、今日そのように設計したとしても、必ずしも1対1であるとは限りません。次に、異なる形式の一意のIDを生成する別のデータストアに変更する場合があります。

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

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

于 2014-07-18T21:19:21.437 に答える
0

RESTful APIは、リソース中心の設計アプローチに重点を置いたアーキテクチャスタイルです。

私の意見では、リソースは複数形と名詞の形式のままにしておきます。

たとえば、すべてのリソースには、次の統一されたインターフェイスがあります

POST/customers-リソースインスタンスを作成するためのPUT/customers/{customerId}-特定のインスタンスを更新するためのGET/customers-検索顧客用です。したがって、@ Ray、検索はURI自体の一部である必要はありません。サポートする必要のあるフィルターまたはクエリパラメーターは、それ自体が存在する必要があります。GET / customers/{customerId}-顧客の特定のインスタンスを取得するにはDELETE/customers/{customerId}特定のインスタンスを削除するには

複数形の理由は、工場とし​​て振る舞うからです。たとえば、リソースの新しいインスタンスを作成しようとすると、そのインスタンスは存在しないため、自己インスタンス上に存在することはできません。したがって、特異点は使用されません。また、リソースの実際のインスタンスを知らない、または保持していない検索/照会にも密接に関連しています。したがって、複数形を強くお勧めします。

ここで問題となるのは、リソースID（データベースの主キー、生成された識別子、または暗号化されたトークン）に何を使用するかです。

私の意見では、データベースの主キーは公開されるべきではありません。リソース識別子は、DB主キーを使用して1-1で設計しないでください。しかし、それはたくさん起こります。生成されたUUIDベースのキーは、シーケンシャルなフォロースルー攻撃を回避するためにはるかに推奨されますが、世界は常に理想的ではありません。

トークンまたは暗号化されたトークンに戻ることは、機密性の高いAPIに推奨されるアプローチであり、2つの別々のアプリケーション間でデータ交換が実行されます。これを使用している場合、暗号化/復号化はAPI側でのみ行う必要があります。つまり、サブリソースの暗号化されたキーは、親API応答の一部として返される必要があります。そうしないと、目的が損なわれます。

于 2021-09-14T22:14:07.607 に答える