0

たとえば、toaとaを含むというエンティティがServiceConfigあります。フィールドを含めずに返されると、次のようになります。pointerServiceProfessional

{
    'type': '__Pointer', 
    'className': 'Service', 
    'objectId': 'q92he840'
}

その時点で、彼らはそのサービスを取得するために再度クエリを実行できます。Serviceただし、名前が必要になることがよくあります。その場合、毎回サービスを取得するために再度クエリを実行する必要があるのは非効率的です。

オプション：

  1. を自動的に返しますService。Industryその場合、必要な場合に備えて、そのためにも自動的に返すService必要があります...すべてに同じことが当てはまります。ここではデータが頻繁に返されるようです。

  2. includes含めるエンティティを指定するパラメータを渡すことを許可します。Formatは文字列の配列であり、a.を使用するとサブクラスを含めることができます。この場合['Professional', 'Service.Industry']は機能します。

あるソリューションが他のソリューションよりも優れている理由を誰かが特定できますか？最後の解決策が最善だと思いますが、私が見たAPIで行うのは一般的ではないようです。

4

1 に答える 1

1

これは、初期バージョンをリリースする前に時間を費やすのに適したAPI設計の決定です。どちらのアプローチも有効であり、クライアントがAPIを使用する最も一般的な方法が何であるかによって異なります。

考慮できる点は次のとおりです。

  1. すべてのデータを事前に提供しない最初のアプローチをお勧めします。効率性が重要な場合もあれば、セキュリティが重要であり、追加の重要なデータが必要に応じて承認された場合にのみ取得されるようにすることも重要です。
  2. 2番目のアプローチを実装すると、APIの設計/コーディング、およびテストを行うために、チームの一部でより多くの労力が必要になります。したがって、リリース1.0にどれだけの労力を費やしたいかを検討することをお勧めします。
  3. たとえば、ネストされたデータがあるため、2番目のアプローチが役立ちます。実際のところ、いくつかのパブリックAPIがそれを実行します。たとえば、LinkedInのパブリックAPI、特にファセットセクションを見てください。ここでは、返したいフィールドや追加情報を指定できます。
  4. 作成したクライアントアプリケーションのいくつかを見て、いずれにせよ事前にデータが必要であることを確認できれば、リターンデータの設計に役立ちます。
  5. 最終的にAPIの使用状況を監視し、呼び出しの数を分析すると、呼び出されたメソッドから、次に何をすべきかについて適切な情報が得られます。

選択をしなければならず、努力の面でもう少し余裕があれば、最初は単純なバージョンであっても、2番目のオプションを選択します。

于 2013-02-20T04:10:18.047 に答える