1

可以使用 SharePoint 自己的本机 REST API 或使用 Microsoft Graph API 访问 SharePoint Online。我已经简要探讨了这两个 API，并看到了功能方面的差异，例如，SharePoint API 具有函数类型方法调用 (GetByTitle())，而 Graph API 似乎支持基于身份的访问，或“站点路径” . 我的观点是，SharePoint 可以通过在 URL 中使用“函数”来轻松访问资源，但是，我不确定它是否是 RESTful。了解您对这方面的看法会很有帮助。

鉴于推荐的前进方式有两个选项（SharePoint 和 Graph），考虑以下标准：

  1. 未来证明 - 在增强方面，来自 Microsoft 的支持
  2. 表现
  3. 功能覆盖 - 考虑当前版本的 Graph API

另外，如果有人分享链接，我找不到任何关于此的 Microsoft 建议。

谢谢。

4

2 回答 2

4

我推荐 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 查询和订阅通知的功能，以查看文件和文档中的更改。

于 2020-01-14T17:32:48.340 回答
1

I was under the impression that the Graph API was meant to centralize things, make one endpoint to connect to all Sharepoint services via API. With that in mind, I wonder if we shouldn't be asking which is the better option but rather we should be asking when the so-called native option will be end of lifed. Graph is more future proof in the sense that this is the direction MS is taking. I can't speak to performance personally. As far as functionality, I can't imagine that Graph is functionally worse than previous iterations of SP. It might be functionally different. But it should expand API functionality.

于 2020-03-05T16:27:51.960 回答