2

したがって、2 つの API を作成しているとしましょう。Car API と AutoService API。Car API は、自動車エンティティに関連するリソースを管理します。AutoService API は、自動車の修理サービスを提供する自動車サービス小売エンティティに関連するリソースを管理します。

アプリケーションが両方の API を使用するとします。特定の自動車エンティティの自動車サービス エンティティを作成します。そのため、Car API を使用して自動車リソースを作成/編集し、それを AutoService API に渡して、その特定の自動車エンティティのサービス ログを作成します。これは、AutoService API のサービス ログ エンティティが、API の外部リソースであるエンティティを参照していることを意味します。

問題は、この依存関係を処理するためのベスト プラクティスは何ですか? 私の最初のアイデアは、サービス エンティティに 2 つのプロパティを作成することです。externalOwner および externalOwnerHost。externalOwner エンティティは、car エンティティの ID にマップされます。externalOwnerHost は、外部所有者の起源を記述します/auto/car。この関連付けを使用して、externalOwnerHost を指定して外部所有者エンティティにアクセスする方法をアプリケーション クライアントが独自に判断するための規則を作成します。GET /auto/car?fields=したがって、この例では、アプリケーションは、リソースのホストを認識していれば、使用できるほどスマートである必要があります。これはベストプラクティスですか？皆さん、もっと良いアイデアはありますか？

4

1 に答える 1

0

依存関係を理解せずに依存関係を呼び出す必要がある場合は、エンティティを呼び出すための子 URL を単一のフィールドに保存します (例: /auto/car/12?fields=...)。

しかし、API の消費者は API から返されたデータを消費する方法を理解する必要があるため、これがどれほど簡単なのか疑問に思います。あなたの例では、これは AutoService API が Auto API データの処理方法を理解する必要があることを意味します。

したがって、私の最終的な推奨事項は、何のために設計しているかによって異なります。これが表示用の場合は、自動サービスにIDを知らせ、自動固有のコントロールを含める方法を知ってもらいます。これが処理用である場合は、CarId を使用して、AutoService API にデータの取得方法とコードでの使用方法を正確に理解させます。データベースにはありません。

于 2016-09-04T18:27:00.760 に答える