RESTful API 最佳实践及 OAuth2.0 闭环
4.00/5 (6投票s)
这份最佳实践列表旨在帮助您掌握分析供应商如何实现 OAuth2.0、如何与 RESTful API 交互，并最终获取最终用户数据的工具和知识。
点击下方按钮，免费下载 RAD Studio 包含 C++Builder 的试用版，尝试文中引用的代码示例和资源。
引言
组成物联网的许多设备和 الجهاز要求最终用户通过第一方应用程序将数据同步到云服务。然后，硬件供应商的云服务通过 RESTful API 将最终用户数据暴露给开发人员。每个供应商都有责任实现 OAuth2 协议并为其服务定义自己的 RESTful API，因此，如何连接、授权以及最终使用最终用户数据没有统一的解决方案。
这份最佳实践列表旨在帮助您掌握分析供应商如何实现 OAuth2.0、如何与 RESTful API 交互，并最终获取最终用户数据的工具和知识。
#5 - OAuth2.0 授权框架定义
《OAuth2.0 授权框架》规范由 IETF 在 RFC 6749 中定义。OAuth2.0 的目标是将资源所有者（最终用户）凭证与其资源（最终用户数据）分离。资源服务器（供应商云服务）向客户端（第三方应用程序）提供一套独立的凭证，以授予对资源的访问权限。这有效地使第三方应用程序能够在无需存储用户名和密码的情况下访问最终用户数据。
所有 OAuth 事务都通过 HTTP 进行。
在物联网供应商的上下文中，OAuth2.0 定义了以下四个角色：
资源所有者
代表使用第一方应用程序将物联网数据同步到供应商云服务的最终用户。供应商云服务必须提供一种机制，供资源所有者授予对受保护资源的访问权限。这通常通过供应商的门户网站登录网关完成。
资源服务器
能够识别和处理有效访问令牌（access_tokens）并交换受保护资源访问权限的供应商云服务。受保护的资源通常是最终用户数据，代表由物联网小工具和设备收集的传感器或其他数据。
client（客户端）
这是第三方开发人员将创建的应用程序，它将代表最终用户（资源所有者）最终使用最终用户数据（受保护资源）。该应用程序可以作为桌面应用程序、移动应用程序、中间件、其他企业服务，甚至可以是物联网设备本身。
授权服务器
在成功验证资源所有者身份并获得授权后，能够向客户端颁发访问令牌的供应商云服务。
访问令牌（access token）根据 RFC 6749 标准定义为：
"表示特定范围、生命周期和其他访问属性的字符串。访问令牌由授权服务器在资源所有者同意的情况下颁发给第三方客户端。客户端使用访问令牌来访问资源服务器托管的受保护资源。"
#4 协议流程 - 获取访问令牌
资源所有者（最终用户）向应用程序提供授权的一种方式是使用 Web 浏览器组件，该组件允许输入用户名和密码到资源服务器（供应商云服务）。有关此过程的工作示例，请参阅我关于使用 MISFIT REST API 的博客文章。
为了访问受保护的资源，客户端必须在 RESTful API 调用中包含访问令牌。以下步骤是根据 RFC 6749 标准获取有效访问令牌的通用概述。
- 客户端向资源所有者请求授权。授权请求可以直接向资源所有者发出，或者最好通过授权服务器作为中介间接发出。
- 客户端接收到授权授予，这是一个代表资源所有者授权的凭证，使用本规范定义的四种授权类型之一或使用扩展授权类型来表示。授权授予类型取决于客户端请求授权的方法以及授权服务器支持的类型。
- 客户端通过向授权服务器进行身份验证并提供授权授予来请求访问令牌。
- 授权服务器验证客户端身份并验证授权授予，如果有效，则颁发访问令牌。
- 客户端通过提供访问令牌来请求资源服务器上的受保护资源，并进行身份验证。
- 资源服务器验证访问令牌，如果有效，则处理请求。
#3 本地存储访问令牌
一旦获得有效的访问令牌，最好将其保存在客户端设备受保护的内部存储中。使用 INI 文件 存储访问令牌，其优点是可以使用 TIniFile 类简化数据读写。使用 INI 文件可以避免在每次客户端应用程序运行时都必须获取新的访问令牌。
在使用存储的访问令牌进行 RESTful API 调用以获取受保护资源之前，请先进行一次测试调用，以确保令牌仍然有效。如果令牌无效，客户端应用程序应重新启动访问令牌请求过程，然后更新 INI 文件中的已验证访问令牌。
加载和部署文件可通过 System.IOUtils 单元进行简化，该单元使得为 Object Pascal 和 C++ 创建、更新和删除 INI 文件非常直接。
请注意，不要将 INI 文件存储在客户端设备上任何可公开访问或共享的文件空间中。例如，在 Android 上，INI 文件应放在 assets\internal 目录中。
在 C++ 中，可以获取文件的句柄。
IniFilePath = System::Ioutils::TPath::Combine(
System::Ioutils::TPath::GetDocumentsPath(), "vendor_service.ini");
Ini = new TIniFile(IniFilePath);
一旦获得 INI 文件的句柄，就可以查询其内容。
AccessToken = Ini->ReadString( "VendorServiceName", "accessToken", "" );
一旦获得有效的访问令牌，您就可以调用 RESTful API 服务了。
#2 使用 REST 调试器和 REST 组件进行 RESTful API 调用
REST 调试器构建在 Embarcadero REST 库之上，该库是一个用于访问基于 REST 的 Web 服务的框架（REST 代表 Representational State Transfer）。REST 调试器允许开发人员进行即席 RESTful API 调用，并轻松地浏览返回的任何 JSON 数据。REST 调试器能够生成 REST 组件，这些组件可以直接复制并粘贴到 Appmethod IDE 中。这是一种非常方便、快速且强大的方法，可以原型化和构建 REST 集成，并将功能与您的应用程序集成。
这里有一系列很棒的 DocWiki 条目，涉及 REST 调试器和 REST 组件：
http://docwiki.embarcadero.com/RADStudio/XE7/en/REST_Client_Library
http://docwiki.embarcadero.com/RADStudio/XE7/en/REST_Debugger
http://docwiki.embarcadero.com/CodeExamples/XE7/en/RESTDemo_Sample
还有一些博客文章和视频详细介绍了如何使用 REST 调试器和 REST 客户端库。
利用 REST 和 C++Builder for iOS 乘风破浪
使用 REST 调试器和 REST 组件查询 Twitter
使用 REST 调试器和 REST 组件控制飞利浦 Hue Lux 灯
#1 使用中间件解决方案聚合数据
物联网小工具和设备正在生成海量数据，这为新的有意义的分析创造了机会。物联网数据分析为供应商创造了新的收入来源。尽管最终用户数据（受保护的资源）通过 RESTful API 调用开放可用，但访问可能会受到限制。
在消费受保护资源方面，并非所有供应商都会以相同的方式公开最终用户数据。有些会限制 RESTful API 调用的数量，有些则会限制日期范围，例如只允许查询过去 30 天的数据。
这可能会给需要可靠访问最终用户数据的客户端应用程序带来问题。供应商对 RESTful API 调用的限制可能会完全破坏客户端应用程序所需的深度功能。为了解决这个问题，并真正拥有最终用户数据，可以引入中间件解决方案来创建聚合数据源。
Enterprise Mobility Services (EMS) 是面向当今互联、分布式应用程序的新型 turnkey 解决方案，提供易于部署的中间件服务器，可托管可加载的自定义 API 和数据访问模块。它基于开放的标准技术，包括 REST HTTP 调用和 JSON 数据格式，并提供主要的 SQL 数据库驱动程序以及加密的嵌入式和服务器 SQL 数据库。凭借其用户管理和身份验证以及用户和 API 分析功能，Enterprise Mobility Services 是实现移动应用程序安全访问企业数据库的理想选择。EMS 是一个无状态、RESTful、可伸缩且安全的中间件解决方案。
当给定的物联网设备生成新数据时，EMS 服务器可以调用供应商的 RESTful API 并定期获取新生成的受保护资源副本。依靠您自己的 RESTful API 层将确保您的客户端应用程序能够不受限制地访问系统中的所有受保护资源。
有关 EMS 服务器的更多信息，请查看以下资源：
了解更多.