2017-10-20 24 views
2

グループAPIと/Conversationsエンドポイントから、会話のリストを取得できます。グループアプリケーションを見ると、画像を持つユーザーを見ることができます。Microsoft Graph Groups APIでユーザー参照を取得するにはどうすればよいですか?

しかし、APIから返されたデータには、ユーザールックアップに使用するデータはありません。

私は一意ではない名前だけでなく、少なくともメールアドレスを期待しています。すべてのスレッドと投稿をトラバースせずにユーザーを取得する効率的な方法はありますか? APIから

データ:

{ 
    "@odata.context": "https://graph.microsoft.com/v1.0/$metadata#groups('{id}')/threads", 
    "value": [{ 
      "id": "{id}", 
      "topic": "Test main thread", 
      "hasAttachments": false, 
      "lastDeliveredDateTime": "2017-10-20T11:35:04Z", 
      "uniqueSenders": [ 
       "Jonas Stensved" 
      ], 
      "preview": "{message preview content}", 
      "isLocked": false 
     }, 
     { 
      "id": "{id}", 
      "topic": "The new Test group is ready", 
      "hasAttachments": false, 
      "lastDeliveredDateTime": "2017-10-13T10:33:03Z", 
      "uniqueSenders": [ 
       "Test" 
      ], 
      "preview": "{message preview content}", 
      "isLocked": false 
     } 
    ] 
} 

グループアプリでグループがどのように見えるか:

[Groups App on iOS]

答えて

0

あなたは、グループメンバーのリストを取得し、それらを反復処理することができます。グループのサイズによっては、ページングが必要な場合があります。詳細については、docs:https://developer.microsoft.com/en-us/graph/docs/api-reference/v1.0/resources/group

こちらをご覧ください。

+0

もちろん、問題は良い方法でこれを行う方法です。回避策を見つけることができません。 –

1

それはここでオブジェクト階層を打破するために役立つかもしれない:

  1. Group - 会話のリソースのコレクションに親
  2. Conversation - 親への -
  3. Threadスレッドリソースのコレクションに親郵便リソースのコレクション
  4. Post - ユーザーがグループに送信した実際のコンテンツ

リソースがThreadにマップされていることを確認するには、スレッド内に含まれるPostリソースを見つけるために別のレベルをドリルダウンする必要があります。

$expand=postsパラメータを使用してPostsコレクションを展開できます。 ($select=from)$expandもありますので、Userリソースにマップする必要があるプロパティのみを返します。

ので、このクエリ:あなたはthis Graph Explorer exampleを使用して、この自分を試すことができます

{ 
    "id": "{thread-id}", 
    "topic": "New Training Plans", 
    "hasAttachments": false, 
    "lastDeliveredDateTime": "2017-07-31T18:59:05Z", 
    "uniqueSenders": [ 
     "HR Taskforce" 
    ], 
    "preview": "{thread-preview}", 
    "isLocked": false, 
    "[email protected]": "https://graph.microsoft.com/v1.0/$metadata#groups('{group-id}')/threads('{thread-id}')/posts(from)", 
    "posts": [{ 
     "@odata.etag": "W/\"CwAAABYAAADE9kXbLjqkSJUGeLzs6eumAAAAAA0/\"", 
     "id": "{post-id}", 
     "changeKey": "CwAAABYAAADE9kXbLjqkSJUGeLzs6eumAAAAAA0/", 
     "from": { 
      "emailAddress": { 
       "name": "HR Taskforce", 
       "address": "[email protected]" 
      } 
     } 
    }] 
} 

/v1.0/groups/{group-id}/threads?$expand=posts($select=from) 

はあなたにこのようなThread結果を提供します。

+0

はい、もちろん可能ですが、それはクライアントを遅くするでしょう。すべての負荷でスレッドを横断している10,000人のユーザーがいる場合はどうなりますか? –

+0

ペイロードのサイズは影響を与える可能性がありますが、必要なフィールドの最小数を選択することで少し軽減できます。ユーザーが詳細にドリルダウンする必要がある場合は、いつでも追加の詳細を表示するために2度目の呼び出しを行うことができます。もう1つのオプション(と私がたくさん使用する)は、サーバー上の結果を非常に短い期間キャッシュすることです。これにより、バックエンドへの500件の同時リクエストが同時に500件のコールを呼び出すことがなくなります。 10〜30秒のキャッシュを持つことは、パフォーマンスに大きな影響を与える可能性があります。 –

+0

はい、でも、ユーザーに一意の参照がないというのはやや驚くべきことです。少なくとも電子メールは高く評価されます。 Graph APIを意味のある方法でユーザーに提供できるように、すべてを長期間キャッシュし、Webhookを使用してキャッシュを更新する必要があります。 –

関連する問題