Microsoft Graph 统一微软所有 API 的访问

在旧金山举行的微软Build 大会上，InfoQ 有机会采访了Microsoft Graph API 的架构师 Gareth Jones 。Microsoft Graph 旨在通过提供统一的 API 端点简化开发人员的工作。

微软的产品广泛应用于世界各地的大多数企业中，看看他们在那种规模下如何解决这个问题会很有意思。让我们来看一下，关于 Microsoft Graph API，Jones 都说了什么。

InfoQ：您好，Gareth。您能介绍下自己和您在微软的新角色吗？

Gareth Jones：我是 Microsoft Graph 团队的一名 API 架构师。我大约是在 5 个月之前加入的，之前的几年，我都在设计 OneNote API。

我在 OneNote 团队所做的其中最后一件事就是将 OneNote 和 Microsoft Graph 连接起来。我认为，那是一个超级让人兴奋的项目，那段经历让我想要加入这个团队。

InfoQ：一般说来以及在微软内部是什么激发了您对 Web API 的兴趣？

Jones：我第一次接触 Web API 是在 Visual Studio 团队工作的时候。那会，我们正在构建一个连接 CodeLens 服务的 API。对我而言，那是一种新的设计体验。之前，我设计过许多.NET API，而且我非常享受 API 设计的过程，将那些技巧应用在 Web 上是一项极大的挑战。当有机会从事 OneNote API 设计时，我迫不及待地就去做了。而且，在学习设计 Web API 的过程中，通过像 APICraft 和 APIStrat 这样的社区，我更广泛地参与到了 API 社区中。

OneNote 是一个很有趣的 API 设计问题，因为它有许多结构化数据是在层次结构的页和节中，但它也有许多非结构化数据是以格式非常自由的画布形式呈现。将那两种东西拟合到一个一致的 API 中是一项非常有意思的工作。

InfoQ：您能向我们更详细地介绍下 Microsoft Graph 吗？它是如何提升微软现有的 Web API 的价值的？它主要面向什么应用场景？

Jones：Microsoft Graph 的核心价值是统一微软的 API，将微软所有的 API 都整合到具有单一身份验证过程的单一端点的单一 URI 命名空间中，提供一种更简单的开发体验；但如果只是这样，那只能是一个 Microsoft API，而不是 Microsoft Graph。

Microsoft Graph 的根本不同在于，将所有的 API 整合到一起，允许我们在 API 上进行智能推理，并提取实体之间的关系，这样，我们就可以实现增值，让应用程序更智能。

例如，我们的合作伙伴 Starbucks 可以轻松使用 Microsoft Graph 的 People API，在他们即将推出的 Outlook 插件中，基于以往的通信模式，挖掘你很可能会安排与哪些联系人召开一次会议的线索。

InfoQ：下一步，除 Graph 之外，你们会继续提供单个的 API 吗？例如，它和 OneDrive 及其 API 之间的关系是怎样的？

Jones：现有的 API 当然不会消失，但我认为，你会看到，由于带来了额外的价值，微软将主要通过 Microsoft Graph 提供新的 API。

InfoQ：你们刚刚宣布了一个期待已久的读 / 写 Web API，用于操作存储在云上的 Excel 电子表格。您能更详细地描述下这项功能吗？

Jones：Excel 一直有数以百万计的企业在桌面上使用它，现在，借助 Microsoft Graph Excel API，将那种逻辑直接连接到业务线应用程序简单了许多。你现在可以与财务应用同步 Excel 电子表格数据。借助丰富的图表可视化和外部资源数据绑定，你能真正地构建激动人心的解决方案。

InfoQ：在身份验证和授权方面，Microsoft Graph API 如何解决所有那些用户、应用程序和数据的安全管理所带来的复杂性？

Jones：好的，这当然需要 API 社区的帮助，围绕 OAuth 2.0 进行标准化，因此，至少协议是明确的，但另一方面，从历史角度看，微软有两种不同类型的授权系统，一个面向客户，一个面向企业。

为了简化开发人员这方面的工作，我们近日随 Microsoft Graph 推出了身份验证端点的 2.0 版本，针对客户、企业和教育场景，以一种标准的方式，将面向应用程序注册和身份管理的开发人员情境整合成一个单一的门户和单一的端点。

此外，OpenID Connect 现在正迅速成为一个公认的登录验证标准，完善了 OAuth 的授权过程。

InfoQ：Microsoft Graph 的开放性和扩展性如何？你们的合作伙伴可以像使用 Visual Studio 插件扩展 Visual Studio 那样，使用他们自己的数据和服务扩展这个 Graph 吗？

Jones：对于 Microsoft Graph，我们的计划无疑是完全可扩展。现如今，Graph 的部分 API 已经允许你使用自己的属性扩展实体，我们正努力让其成为所有 Graph API 的一个标准功能。我们的最终目标是让更广泛的客户数据成为 Graph 的一部分，并充分利用由此带来的智能关系。

InfoQ：在过去的十年中，微软一直在开发 OData。如今，OData 在微软的 API 领域里处于什么位置？它在更广泛的生态系统中应用情况怎样？

Jones：在微软，我们发现，OData 在 API 建模和描述方面是一个非常实用的工具，特别是 Microsoft Graph 如此重视不同 API 中实体之间的关系以及关系导航的价值。

经过几年的发展，OData 现在已经非常符合如今的 REST API，并于最近在 ISO 层面进行了标准化，因此，将它作为强交互情境的基础，我们很安心。

当然，我们认识到，社区对于 OAI/Swagger 投入了很大的精力，因此，我们也希望确保在那方面有一个精彩的故事。

Microsoft Graph 的所有服务都是通过 OData v4.0 提供的，你只要请求 $metadata 端点就可以获得实时元数据。许多终端用户工具，如 Excel、Power BI 或 Salesforce，可以利用 OData 直接消费 Graph 数据。那样，高级用户真就可以在聘用开发人员之前从 API 获取价值了。

InfoQ：最近，微软宣布加入 Eclipse 基金会，参与以 Eclipse Che 项目为基础的云 IDE。你们有在新一代 IDE 中支持微软 Web API 的计划吗，尤其是 Microsoft Graph？

Jones：在 Graph 方面，我们目前还没有什么具体的工作要做，但那无疑是我们未来会考虑的东西，我们在许多平台上已经有了身份验证库和 Graph SDK，包括 Java，因此，从那里出发开始下一步的工作是合理的。

InfoQ：在微软，有什么工程问题阻碍了所有那些 Web API 的交付吗？你们改进工作流程和工具来解决它们了吗？

Jones：将微软许多有自己 API 的团队团结在一起创建一个一致的 Microsoft Graph，最难的问题是模式的数据建模。

这里有一个例子：在微软，我们至少有三个团队从事 Outlook、Planner 和 WunderList 的开发，每个团队都有自己的任务表示形式，所有这些形式的应用场景都稍有不同，但就数据来看，它们显然有大量的重叠。

为统一后的任务 API 创建一个好的模型是一个有趣的问题。你不会希望在杂货店购买奶酪的任务默认显示在看板上。在数据模型合并领域，没有任何真正意义上的好工具，因此，随着工作进行，我们创建了其中的部分工具。

这里的真正挑战是，在恰当的时间介入项目生命周期，确保在一个足够早的阶段考虑设计统一的模型。

InfoQ：微软最近加入了“开放 API 倡议（Open API Initiative）”。微软使用了多少 API 定义语言，如 Swagger、RAML 和 API Blueprint？

Jones：在微软，API 定义语言无处不在。你会注意到，Swagger 已经深深扎根于许多 Azure API 产品，Visual Studio 也有一个针对 Swagger 的 API 客户端向导。我先前的团队，OneNote 团队，就是使用 API Blueprint 设计 API 的，当然，OData CSDL 的应用也相当广泛。

和其他人一样，我们希望整合一下，当然，我认为你可以期待 OAS 和 OData CSDL 接下来成为微软的基本规范。

InfoQ：您怎么看超媒体 API？它与遵照一定格式定义超媒体 API 不是矛盾吗？

Jones：我认为，在未来几年中，超媒体将越来越普遍，但不是每个人都做好了准备。构建一个灵活的系统，可以对超媒体响应的动态特性作出回应，是一种观念的转变，需要花一些时间去适应。

OData 为我们提供了它们两者的其中一些最大的优点。如今，OData 的典型应用是使用预定义的关系，但如果你是一个超媒体迷，那么你可以要求将元数据包含到响应报文中，并以此为基础构建一个完全动态的系统。

如果你看过任何最新的 Cortana 演示，在里面，我们主动为用户提供了贯通业务和个人生活的建议，那么就很容将其与 API 进行类比，静态关系根本不够用。你会需要通过一个 API 利用超媒体来提供这些主动建议。

我认为，使用超媒体注解类似机器学习这种更为传统的 API，在这类场景中，我们可能会看到超媒体 API 的首次大规模实施。

InfoQ：微软 API 领域接下来会发生什么？

Jones：对于 Microsoft Graph，我们正致力于两项主要的支柱性工作：第一项显而易见，就是增加 API 覆盖，让你可以使用 Microsoft Graph 做更多的事。我正考虑把类似 Microsoft Intune 和 Skype 这样的产品作为范例。

另一项支柱性工作是进一步智能化。近日，我们向 Graph 的 FindMeetingTimes API 添加了一个调度算法，我们希望添加更多类似的东西。我们还希望添加深度 Graph 查询功能。

InfoQ：在 Web 上，RPC 似乎在不断地复兴，如来自谷歌的 gRPC。您能分析下这种现象吗？微软有任何类似的方案吗？

Jones：我认为，客户大多对我们务实的 REST 方法相当满意，必要的时候，我们向 OData 添加了动作或函数，而不是教条式地遵循 REST 原则。因此，我们没有感觉到那种压力。在流和实时数据方面，我们确实每天都会看到 REST 的局限。渐渐地，客户简直期望每个系统都有实时功能。

InfoQ：根据您的经验，API 开发人员多久能从代码驱动的 API 开发工作流过渡到契约驱动？API 工具已经为这个更加工业化的阶段做好准备了吗？

Jones：根据我在微软团队的工作经验，开发人员非常喜欢有更多形式化的东西，因为这样在解释规范时就不用臆测了。更大的挑战可能在于，让业务人员和架构师习惯工具和那种工作准确度。

借助部分内部构建的工具，我们非常注重预先设计文档和开发体验，并在那些文档中包含准确的元数据以驱动开发流程。这将模式设计过程和真实的 API 使用场景联系了起来，我们觉得那非常重要。

有时候，我们将契约驱动设计看作是从中间开始。我们努力推动上游将设计编入 API 文档的用例描述中。

InfoQ：您对 Web API 的未来怎么看？接下来需要发生什么样的大事件才能加速 API 在各种规模的企业中的应用？

Jones：好的，正如前面提到的，我认为实时会成为下一个大事件。REST 非常适合事务型系统，但对于动态交互式应用，你确实需要一个实时通道。看看 API 社区如何关注这个领域将会很有意思。我这里可能会有偏见，但我认为，从现在开始，你会看到更多类似 Microsoft Graph 的孤立 API 整合。将智能机器学习和实体与不同 API 之间的关系联系起来，可以提供巨大的价值。

查看英文原文： Microsoft Graph Unifies Access to All APIs