REST APIが子リソースに対して一意でないIDを持つことは悪いことですか?
たとえば、エンドポイントは次のとおりです。
GET /parent/:parent_name/child/:child_name
:parent_name
は一意ですが、:child_name
はその親に対してのみ一意です。
parent
とchild
は外部システムに存在するリソースであるため、最初は名前を使用することにしました。これにより、APIコンシューマーは、GUIDのようなAPIに固有のIDを取得するための追加のクエリを必要とせずに、直感的に名前をURIに入力できます。
しかし、これは間違いだったのではないかと思い始めています。 child
を使用するエンドポイントには、:parent_name
と:child_name
の両方が必要になりました。 child
がルートであるエンドポイントでも、クエリパラメータに:parent_name
が必要です。
子リソースの一意でないIDを使用したこの設計は受け入れられますか、またはAPI内で一意のIDを生成し、常にそのIDを使用する方が良いですか?
RESTでURLを構築するためのハードルールはありません。常識とベストプラクティスのみです(たとえば、 one のようなガイドが多数あります)。 RESTの観点から見ると、URLがどのように見えるかは重要ではありません。/da39a3ee5e6b4b0d3255b
のようなものは、リソースを識別する限り問題ありません。
あなたの場合、URL全体が特定の時点でのリソース識別子です(エンティティのコレクションまたは単一のエンティティのURLです)。したがって、1つの識別子がより多くのリソースを指す可能性がある重複がないようにURLを適切に構築できる場合は、URLの構築方法やURLに含まれる名前に関係なく問題はありません。
そうは言っても、名前を使用することに決めた場合にはいくつかの問題があります(これらの名前に含まれているものを正確に述べていないので、プレーンテキストと仮定します)。先ほど触れたように、RESTはURLを気にしません。ユーザーのためにそのようなユーザーフレンドリーなURLを作成します。ピープルユーザー。マシンは気にしません。 IDの代わりに名前を含むURLを作成したい場合たとえば、頭のてっぺんから:
これらの人々のような理由のために、通常、そこにIDを貼り付け、それを1日と呼ぶことを好みます。場合によっては、:ID-:Name
(ID、ダッシュ、名前)または:ID/:Name
(ID、スラッシュ、名前)を使用することもあります。 IDはアプリケーションで使用されますが、名前はユーザーの便宜のために存在し、アプリケーションの実際の実行/ルーティングエンジンでは無視されます。例として、この実際の投稿を見て、次の2つのURLを比較してください。
REST一意ではないが一意の複合IDを持つAPIリソースを設計する
REST一意ではないが一意の複合IDを持つAPIリソースを設計する
アプリケーションは、投稿のIDを調べます。これは、人々とSEOのためのものです。
結論として、この質問に対する明確な答えはありません。私が言ったように、ただの常識とベストプラクティス。したがって、常識を使用して、いくつかのベストプラクティスを読んでください。これに対する私の個人的な答えは、上記の問題のために名前を避けようとすることです。名前でめちゃくちゃにすることができますが、(通常は数値の)IDを使うとそれほど難しくありません。名前の代わりにIDを使用すると、APIがより簡単に進化します。