web 服务 - RESTful 基础与基于资源的 API 实践
规范:REST API 设计 Github API v3 overview ;微软
作业:模仿 Github,设计一个博客网站的 API
REST笔记:
将REST架构样式与其他基于网络的样式区分开的主要特征是它强调组件之间的统一接口(图5-6)。 通过将通用性的软件工程原理应用于组件接口,简化了整个系统架构,并提高了交互的可见性。 实施与提供的服务脱钩,从而鼓励了独立的可扩展性。 但是,要权衡的是,统一的接口会降低效率,因为信息是以标准化形式而不是特定于应用程序需求的形式传输的。 REST接口被设计为对于大容量超媒体数据传输是高效的,针对Web的常见情况进行了优化,但是导致的接口对于其他形式的体系结构交互不是最佳的。
REST使用资源标识符来标识组件之间交互中涉及的特定资源。REST连接器提供了一个通用接口,用于访问和操作资源的值集,无论如何定义成员函数或处理请求的软件类型。分配资源标识符的命名机构,使引用资源成为可能,负责随时间维护映射的语义有效性(即,确保成员资格功能不变)。
REST组件通过使用表示来捕获资源的当前或预期状态,并在组件之间传输表示,从而对资源执行操作。表示是字节序列,加上表示元数据来描述这些字节。其他常用但不太精确的表示名称包括:文档、文件和HTTP消息实体、实例或变体。
所有REST交互都是无状态的。也就是说,每个请求都包含连接器理解请求所需的所有信息,与之前的任何请求无关。
REST提供了一组体系结构约束,当作为一个整体应用时,这些约束强调组件交互的可伸缩性、接口的通用性、组件的独立部署和中介组件,以减少交互延迟、加强安全性和封装遗留系统。我描述了指导REST的软件工程原则和选择保留这些原则的交互约束,并将它们与其他体系结构风格的约束进行了对比。
设计良好的 Web API 应旨在支持:
平台独立性。 不管 API 的内部实现方式如何,任何客户端都应该能够调用该 API。 这就需要使用标准协议并创建一种机制,使客户端和 Web 服务能够就交换数据的格式达成一致。
服务演变。 Web API 应能在不影响客户端应用程序的情况下改进和添加功能。 随着 API 的发展,现有客户端应用程序应可继续运行而无需进行任何修改。 所有功能应该是可发现的,使客户端应用程序能够充分利用它。
使用 HTTP 设计 RESTful API 时的一些主要原则:
- REST API 围绕资源设计,资源是可由客户端访问的任何类型的对象、数据或服务。
- 每个资源有一个标识符,即,唯一标识该资源的 URI。
- 客户端通过交换资源的表示形式来与服务交互。 许多 Web API 使用 JSON 作为交换格式。
- REST API 使用统一接口,这有助于分离客户端和服务实现。 对于基于 HTTP 构建的 REST API,统一接口包括使用标准 HTTP 谓词对资源执行操作。 最常见的操作是 GET、POST、PUT、PATCH 和 DELETE。
- REST API 使用无状态请求模型。 HTTP 请求应是独立的并可按任意顺序发生,因此保留请求之间的瞬时状态信息并不可行。 信息的唯一存储位置就在资源内,并且每个请求应是原子操作。 此约束可让 Web 服务获得高度可伸缩性,因为无需保留客户端与特定服务器之间的关联。 任何服务器可以处理来自任何客户端的任何请求。 也就是说,其他因素可能会限制可伸缩性。
- REST API 由表示形式中包含的超媒体链接驱动。