@lsmn
2016-05-07T09:14:43.000000Z
字数 4871
阅读 3541
微软 Graph API
在旧金山举行的微软Build大会上，InfoQ有机会采访了Microsoft Graph API的架构师Gareth Jones。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之间的关系联系起来，可以提供巨大的价值。