web-dev-qa-db-ja.com

REST

私は10種類以下の単純なリソースのセットを使用しており、1対多の関係があります。例えば

  • 注文には多くのエントリがあります
  • エントリには多くのコメントがあります
  • マシンには複数のエントリを関連付けることができます
  • 材料には複数の注文を関連付けることができます

すべてのモデルオブジェクトは一意の主キーによって識別されます

REST HTTP呼び出しを使用して通信します。オブジェクトはどのようにモデル化する必要がありますか？

オプション1：オブジェクトのネスト

関係により、オブジェクトがネストされる可能性があります。

entry{
  PK: '_',
  prop1: '_',
  prop2: '_',
  machine:{
    PK: '_',
    prop3: '_'
  },
  order: {
    PK: '_',
    material: {
      PK: '_',
      prop4: '_'
    }
  }
}

他のオブジェクトについても同様です

オプション2：PKによる参照

このアプローチは、オブジェクトを「平坦化」します。

entry{
  PK: '_',
  prop1: '_',
  prop2: '_',
  machinePK: '_',
  orderPK: '_'
}

最善のアプローチは何ですか？明らかに両方とも明確な長所と短所があります。ハイブリッドアプローチは実行可能なソリューションですか？その場合、「フラット」または「ネストされた」オブジェクトを選択するには、どの基準に従う必要がありますか？それを実装するために使用するテクノロジーに依存する可能性がありますか（ただし、テクノロジーが悪い習慣のようなにおいがするためにモデルを変更する...）？

いくつかのコンテキストを与えるために、私はバックエンドにASP.NET WebApi 2を使用し、フロントエンドにTypeScriptのAngularJSを使用しています

designrestmodeling
6
Giacomo Tagliabue

これは、プログラマーに体験してもらいたい経験と、アプリケーションの複雑さとパフォーマンスへの影響によって異なります。

  • 単一のオブジェクトが大きく、APIのコンシューマーがすべてのデータを事前に必要としない場合は、それを複数のチャンクに分割し、関連するオブジェクトが必要な場合はコールバックするようにすることができます。

  • オブジェクトが大きくなると、サーバーでの処理とパフォーマンスが向上する可能性があり、それ自体が問題になる可能性があるため、それを下げたままにすることをお勧めします。

  • 一方、サブオブジェクトなしでオブジェクトが本当に「不完全」な場合は、一度に送信することを検討できます。

PKは、データベースを扱う人以外の人が理解できる標準的な用語である必要はないと思います。 REST APIの場合、より適切な名前は、EntryId、OrderId、MachineIdなど、またはより一般的にはIdおよびObjectIdなどです。

また、ネストされた要素のObjectIdを常に送信する必要はありません。API自体が関係（つまり、残りの目的の1つ）を明らかにするため、例から、エントリは次のようになります。

entry{
  Id: "42",
  prop1: '_',
  prop2: '_',
}

誰かがエントリのすべての注文を検索したい場合、次のようなものが発行されます。

https://www.example.com/entries/42/orders

これにより、エントリー＃42（必要に応じてページングなど）のすべての注文が取得されます。

REST URLのベストプラクティス についてはこのページを、Rest APIに関する他のベストプラクティスへのリンクについては このページ を参照してください。 OData もご覧ください。これは主にデータを扱い、REST APIの上に構築されているためです。他の意見を明確に検証して入手することを忘れないでください。

3
Omer Iqbal