0

それぞれが州と関係のある都市のコレクションを返す呼び出しを使用してAPIを構築しているとします。州には多くの都市がありますが、都市には1つの州しかありません。

このように、関係を平坦化し、データの基礎となる構造を曖昧にすることを想像できます。

{ cities : [
    { id: 1,
      name: "Los Angeles",
      state: "CA" }
]}

または、都市と州の関係が明確になるようにJSONを構造化することを想像できます。

{ cities : [
    { id: 1,
      name: "Los Angeles",
      state: { id: 1,
               name: "CA" }
]}

APIの利用者は、今のところ、州の名前を知る必要があるだけです。彼はそのIDや州に関する詳細情報を取得する方法を知る必要はありません。どちらの方法でもJSONを構造化することの長所と短所は何ですか？

4

2 に答える 2

2

私の意見では、APIに役に立たない情報を追加するべきではありませんが、@ kgbが言ったように、APIが拡張される傾向がある場合は、そのように設計する必要があります。あなたは都市と州の関係について尋ねました、そして私の意見では、この関係はすでに両方で定義されています。

したがって、APIが状態機能を拡張しないと100％確信している場合は、オプション1を使用する必要があります。わずかな可能性しかない場合は、次のようにすることをお勧めします。

{ cities : [{ 
      id: 1,
      name: "Los Angeles",
      state: { name: "CA" }
  }]
}
于 2012-09-10T08:22:16.500 に答える
1

それは他の消費者に依存します。あなたがいずれかを持っている？する予定ですか？

APIはマシンインターフェースであり、消費者の開発者が両方の構造を使用することも同様に簡単です。「状態」エンティティが複合エンティティではない場合（名前以外の使用可能なプロパティがない場合）、IDを持つ構造ではなく、名前だけを表示することをお勧めします。

将来的に状態IDが役立つ可能性がある場合、または新しいプロパティが状態エンティティに追加される可能性がある場合は、最初から2番目のアプローチを使用する必要があります。APIを変更すると、すでに作成されているソフトウェアが破損するため、APIを変更すると、2つの異なるバージョンがサポートされるようになります。アプローチ1と2の間の変更には、下位互換性はありません。

アプローチ2を使用します。1よりもそれほど複雑ではなく、州のエンティティを拡張する可能性があります。

3番目のアプローチもあります。しかし、それは著しくより複雑です（そしてより拡張可能です）。状態IDのみを返し、状態エンティティを取得するためのメソッドを作成します。

于 2012-09-06T14:54:22.310 に答える