添付ファイルがMicrosoft Graph APIのメッセージエンティティとして表示される

Question

最近、Microsoft Graph APIが添付ファイルを/ me/messagesエンドポイントから返されたメッセージエンティティとして返されていることがわかりました。

次のように再現するシナリオは次のとおりです。

• は自分自身にメールを送信（または他の誰かがあなたにメールを送ることがあります）1つ以上のファイルが添付された
• グラフExplorerで次のクエリを実行します。https://graph.microsoft.com/v1.0/me/messages
• 電子メール自体を表す1つのオブジェクト（これは正しい動作です）と添付ファイルの表現である1つ以上のオブジェクトが存在することに注目してください。

これらの添付ファイル "メッセージ"は元の電子メールと同じ件名を持ち、ボディコンテンツは添付ファイルのファイルコンテンツ（添付ファイルがドキュメントの場合）に設定されていますが、送信者はありませんまたは受信者の場合はisReadステータスがtrueで、isDraftステータスがtrueの場合全くのナンセンス！

私はこれだけはグラフAPIのバグであると仮定することができます - 私は、これは設計によって起こる理由何らかの理由を見ることができません。私はGraph APIを使って約9ヶ月間作業していたことに注目する価値があり、この動作は最近になって起きています。

マイクロソフトの誰かができるだけ早くこれに連絡してください。これはAPIの大きなバグであり、間違いなくそれを使用するほとんどのアプリケーションを壊してしまいます。おそらく安定したv1.0が私たちの下で変更されるという大きな懸念もあります。なぜ次のリリースでv1.1またはv2.0を使用しないのですか？

Answer 1

ご報告いただきありがとうございます。 /me/messagesエンドポイント経由でメッセージを取得すると、この動作も同様に表示されます。 /me/mailfolders/inbox/messagesで検索すると、私はしません。これは実際には重要な手掛かりです。

メッセージのparentFolderIdを見ました。 「正しい」ものは、​​受信トレイのIDです。もう一方は、そうではありませんでした。どんなIDであれ、私はAPIで取得できません（私は404を取得します）。だから、これはおそらく隠しフォルダです。

IDで再生すると、MAPI IDに変換してMFCMapiで開くことができました。それはファイルのフォルダです。だから私はここでのバグは/me/messagesに結果が返ってくるときにファイルフォルダを含めてはならないと思う。開発チームにバグを記録します。