可以使用 SharePoint 自己的本机 REST API 或 Microsoft Graph API 访问 SharePoint Online。我已经简要探讨了这两个 API，并看到了功能方面的差异，例如，SharePoint API 具有函数类型方法调用 (GetByTitle())，而 Graph API 似乎支持基于身份的访问，或“站点路径” .我的观点是，SharePoint 可以通过在 URL 中使用“函数”来轻松访问资源，但是，我不确定它是否是 RESTful。了解您对这方面的看法会很有帮助。
考虑到以下标准，考虑到两个选项（SharePoint 和 Graph），这是推荐的前进方式：
另外，我找不到任何关于此的 Microsoft 建议，如果有请分享链接。
谢谢。
【问题讨论】：
标签： microsoft-graph-api sharepoint-rest-api
我推荐 Microsoft Graph API。我知道它是实际 Sharepoint、OneNote、Planner 等 API 的代理，但他们每天改进图形 api 的方式让我认为它会持续很长时间。假设您正在编写一个想要与许多 Microsoft 应用程序端点连接的应用程序，拥有一个处理所有图形 api 请求的类就足够了，而不是寻找特定的应用程序端点。
性能：我一直在使用 Microsoft graph api 来完成大部分与 SharePoint 相关的工作，它运行良好且快速。在应用中实现之前，我会使用 Graph explorer 检查该图是否真的有效。
功能覆盖：显然，图形是真实 api 的代理，因此它不会覆盖您需要在 SharePoint 中执行的所有流程。例如，我必须创建一个无法通过图形 API 找到方法的 Sharepoint Group。但我假设随着越来越多的人对这些请求进行投票，graph api 也带来了那些新的可能的代理端点。但同样，如果您的应用程序仅使用 Sharepoint，那么我相信我会坚持使用 SharePoint API。为了支持 Graph API，他们还提供了称为 delta 查询和订阅通知的功能，以查看文件和文档中的更改。
【讨论】：
我的印象是 Graph API 旨在集中事物，使一个端点通过 API 连接到所有 Sharepoint 服务。考虑到这一点，我想知道我们是否不应该问哪个是更好的选择，而是应该问所谓的原生选项何时会结束。从某种意义上说，这是 MS 正在采取的方向，图表更具未来性。我不能亲自谈论性能。就功能而言，我无法想象 Graph 在功能上比以前的 SP 迭代更更糟。它可能在功能上有所不同。但它应该扩展 API 功能。
【讨论】：