在 Microsoft Graph API 中显示为消息实体的文件附件 [英] File attachments showing as message entities in Microsoft Graph API

问题描述

最近我们注意到，Microsoft Graph API 一直在将文件附件作为从/me/messages 端点返回的消息实体返回.

重现的场景如下:

• 向自己发送一封电子邮件(或让其他人向您发送一封电子邮件)，其中包含一个或多个文件附件
• 在图形资源管理器中运行以下查询:

  我只能假设这是 Graph API 中的一个错误 - 我看不出有任何原因会按设计发生.还值得注意的是，我已经使用 Graph API 大约 9 个月了，而且这种行为最近才开始发生.

  能否请来自 Microsoft 的人员尽快与此联系?这是 API 中的一个主要错误，无疑会破坏大多数使用它的应用程序.同样令人担忧的是，一个本应稳定的 v1.0 在我们之下正在发生变化.为什么不将 v1.1 或 v2.0 用于下一个版本?

  解决方案

  感谢您的报告！如果我通过 /me/messages 端点检索消息，我也会看到这种行为.如果我通过 /me/mailfolders/inbox/messages 检索，我不会.这其实是一个重要的线索.

  我查看了消息的 parentFolderId.对于正确"的那个，它是收件箱的 ID.另一方面，事实并非如此.无论 ID 是什么，我都无法通过 API 检索它(我得到 404).所以这很可能是一个隐藏文件夹.

  使用这些 ID，我能够转换为 MAPI ID 并使用 MFCMapi 打开它.原来它是 Files 文件夹.所以我认为这里的错误是 /me/messages 在返回结果时不应包含 Files 文件夹.我会向我们的开发团队记录一个错误.

  Recently we've noticed that the Microsoft Graph API has been returning file attachments as message entities returned from the /me/messages endpoint.

  The scenario to reproduce is as follows:

  • Send yourself an email (or have someone else send you an email) with one or more file attachments
  • Run the following query in Graph Explorer: https://graph.microsoft.com/v1.0/me/messages
  • Notice that there will be one object which represents the email itself (this is correct behaviour) and one or more objects which are representations of the file attachments.

  It's also worth noting that these attachment "messages" have the same subject as the original email, the body content is set to the file content of the attachment (if the attachment is a document), there are no senders or recipients, they have an isRead status of true, and an isDraft status of true. Utter nonsense!

  I can only assume this is a bug in the Graph API - I can't see any reason why this would happen by design. It's also worth noting that I've been working with the Graph API for around 9 months and this behaviour has only recently started happening.

  Could someone from Microsoft please get in touch regarding this as soon as possible? This is a major bug in the API which will undoubtedly break most applications using it. It's also a great concern that a supposedly stable v1.0 is being changed underneath us. Why not use v1.1 or v2.0 for the next release?

  解决方案

  thanks for reporting! I see this behavior as well if I retrieve messages via the /me/messages endpoint. If I retrieve via /me/mailfolders/inbox/messages, I do not. This is actually an important clue.

  I looked at the parentFolderId of the messages. For the one that is "right", it was the ID of the Inbox. For the other, it was not. Whatever ID it is, I can't retrieve it via the API (I get a 404). So it's likely this is a hidden folder.

  Playing with the IDs, I was able to convert to a MAPI ID and open it with MFCMapi. It turns out it's the Files folder. So I think the bug here is that /me/messages should not include the Files folder when returning results. I'll log a bug with our development team.

  这篇关于在 Microsoft Graph API 中显示为消息实体的文件附件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！