RESTful再理解

简介: 目录目录前言RESTful的目的REST的含义表现层状态转化无状态协议HTTP最后前言这是在经过一段时间的积累后,对RESTFul框架的再一次更深入的理解。

目录

前言

这是在经过一段时间的积累后,对RESTFul框架的再一次更深入的理解。希望能够将零散的知识点连接成线,相织成面。

RESTful的目的

RESTful由Roy Thomas Fielding在2000年提出,旨在探索两大计算机学科方向–软件&网络 的交叉点。
软件开发:关注软件设计的分类、设计方法的实现。
网络开发:关注系统之间的通信行为的细节和如何改进特定通信机制的表现。
在传统的行业环境中,软件开发很少去评估不同的设计选择对系统行为的影响。在网络开发中也常常忽略了应用程序的交互风格改变比改变互动协议对整体的表现形式有着更大的影响。
而RESTful提出的目的,用设计者的话来说就是:希望在符合架构原理的前提下,理解和评估以网络为基础的应用软件的架构设计,得到一个功能强、性能好、适宜通信的架构。即RESTful架构设计风格的Web service是建立在网络传输协议HTTP上的特别的应用网站,或者应该称之为”软件”会更加符合REST的初衷。

REST的含义

REST(Representational State Transfer)表现层状态转换

表现层

在Web service的表现层中,Resource Request Handler会接收Client通过HTTP协议发送的无状态请求,在接收请求后再向业务逻辑层请求服务并执行结果返回给Client。除此之外,表现层中的Resource Request Handler还能够确定对自动化客户端公开的概念性实体,而这种实体是具有多种表现形式的数据或服务,也被称之为资源。同时还会为资源分配URI作为唯一的标识,在网络中访问这个URI就是获取一个资源。
需要注意的是:**URI只代表资源的实体,不表示资源的表现形式。我们需要在HTTP请求的头信息中用Accept和content-Type字段来指定相应的资源的表现形式。即:**URI指定资源、HTTP请求中的Accept、content-Type字段指定资源的表现形式
在不同的客户端中可能会请求同一个资源的不同表现形式,例如:我们请求Server中的同一个文本资源时,可能有人需要以XML格式获取、有人可能需要以JSON格式获取。这种格式的需求是由Client发出的请求确定的,而这种资源格式的转换是发生在表现层中的,先由Resource Request Handler对资源的格式进行确定后再做出响应。这种特性使得Web service可以部署到大量需求不同的客户端之中,并且由于无状态原则的特性,使得其非常适合运行在分布式系统中。

状态转化

这种状态指的是请求的状态而不是资源的状态。从客户端的角度出发,其可以通过HTTP的标准方法POST(新建)、DELETE(删除)、GET(获取)、PUT(更新)来操作和修改Server上的资源。而且这种转化建立在表现层中,所以称之为”表现层状态转化”。

无状态协议HTTP

为什么RESTful要加入无状态原则?
这是由于RESTful选择了HTTP协议来同时充当传输协议和应用协议。
那为什么RESTful要选择HTTP协议?
这是从RESTful的设计初衷决定的。Roy Thomas Fielding希望能够建立一个框架去实现基于网络协议的应用软件,而软件的形式就是”网站”,那么协议自然就是HTTP了。
协议的状态:指的是下一次传输能够”记住”这次传输信息的能力。有状态的请求会在Server对请求做出响应后,将请求的状态信息保存在Server的Session中,使得下一次Client传输的信息能够与这一次的请求相关联,从而Server能够再次做出应答。但是这也意味着没有保存过Client请求状态信息的Server无法随时与Client建立连接,这并不适合在分布式系统中使用,会造成很高的请求延迟。
相对而言,由于Web Server要面对很多浏览器的并发访问,为了提高Web Server对并发访问的处理能力,在设计HTTP协议时规定Web Server响应HTTP应答报文和文档时,不保存Client发出请求的Web浏览器进程的任何状态信息。这能够实现一个Client在短时间之内两次访问同一个Server对象时,Server进程不会因为已经给Client发过应答报文而不接受第二次的服务请求(并发访问)。出于上述的理由和为了保证服务器内存,Web Server不会保存发送请求的Web浏览器进程的任何信息,因此HTTP协议属于无状态协议。
基于HTTP协议的无状态特性,决定了RESTful风格的请求也是无状态的。这里的无状态指的是Server不会保留有请求的任何状态信息,那么久决定了每一个请求都必须包含有Server可以理解这个请求所需要的全部信息。

最后

RESTful这一设计风格,需要我们在理论和实践的结合中去理解。在往后的时间里,我们会尝试使用Python去实现连接Web service的RESTful API和实现RESTful API。

相关文章
|
安全 Java 网络架构
|
网络架构 API 数据格式
RESTful三理解
目录 目录 前言 Web应用的会话状态 Cookie 资源的表现形式 HATEOAS RESTful 资源 URI 前言 最近看了一篇很赞的RESTful博客,传送门:http://www.cnblogs.com/artech/p/3506553.html 本篇是RESTful的又一次理解笔记,将之前写过的文章做一个总结和消化,应该是关于RESTful的最后一篇基础理论文章,之后会向实践倾斜,通过编写Python RESTful API来更好的消化理论。
1329 0
|
2天前
|
缓存 安全 API
RESTful API 设计的关键技巧
REST,代表表现层状态转移(Representational State Transfer),长久以来一直是 API 服务的圣杯,最初由 Roy Fielding 在其博士论文中定义。尽管它不是构建 API 的唯一方法,但由于其广泛的普及,即使是非开发者也对其有所了解。
|
2天前
|
XML JSON API
RESTful API关键部分组成和构建web应用程序步骤
RESTful API关键部分组成和构建web应用程序步骤
|
2天前
|
缓存 测试技术 API
构建高效的RESTful API:最佳实践与设计原则
在数字化时代,RESTful API已成为连接不同软件系统和服务的桥梁。本文将深入探讨如何设计和实现一个既高效又易于维护的RESTful API,涵盖从请求处理到数据交互的最佳实践,以及如何确保API的安全性和可扩展性。我们将通过具体的代码示例和架构设计,展示如何构建一个遵循REST原则的API,以及如何利用现代框架和工具来简化开发过程。
|
6天前
|
JavaScript API 数据处理
构建高效可扩展的RESTful API:后端开发实践指南
【5月更文挑战第30天】在数字化转型和移动应用日益普及的背景下,构建一个高效、可扩展且易于维护的RESTful API对于后端开发者来说至关重要。本文将深入探讨设计RESTful API的最佳实践,包括如何选择合适的技术栈、实现高效的数据处理以及确保API安全性。通过阅读本文,您将了解如何从零开始构建一个高性能的后端系统,同时保证其在未来可以轻松适应业务需求的变化。
|
7天前
|
存储 安全 API
网络安全与信息安全:防御前线的关键技术深入理解RESTful API设计原则与实践
【5月更文挑战第30天】在数字化时代,网络安全和信息安全已成为维系信息社会运行的核心支柱。本文深入探讨了网络安全漏洞的概念、加密技术的进展以及提升安全意识的重要性。通过对这些领域的分析,旨在为读者提供一个关于如何保护个人和组织资产免遭网络威胁的综合性视角。 【5月更文挑战第30天】 在现代Web服务开发领域,表述性状态传递(REST)已成为构建后端API的一种流行且成熟的架构风格。本文将探讨RESTful API的核心设计原则,并通过实例分析如何将这些原则应用于实际开发中。我们将重点讨论资源的概念化、HTTP方法的正确使用、状态码的准确传达以及API的可扩展性和版本控制问题。通过本文,读者将
|
7天前
|
Web App开发 JavaScript Cloud Native
构建高效可扩展的RESTful API:Node.js与Express框架实践指南构建未来:云原生架构在企业数字化转型中的关键作用
【5月更文挑战第29天】 在数字化时代的驱动下,后端服务架构的稳定性与效率成为企业竞争力的关键。本文深入探讨了如何利用Node.js结合Express框架构建一个高效且可扩展的RESTful API。我们将从设计理念、核心模块、中间件应用以及性能优化等方面进行系统性阐述。通过实例引导读者理解RESTful接口设计的最佳实践,并展示如何应对大规模并发请求的挑战,确保系统的高可用性与安全性。
|
8天前
|
缓存 安全 API
构建高效RESTful API的后端实践
【5月更文挑战第29天】 随着移动和Web应用的兴起,后端服务在软件架构中扮演着愈发重要的角色。本文深入探讨了构建高效RESTful API的实践方法,包括设计原则、性能优化技巧以及安全性考虑。文中不仅阐述了理论知识,还结合实例分析,旨在为开发者提供一套实用的后端开发指南。
|
9天前
|
应用服务中间件 API nginx
使用Python和Flask构建RESTful Web API
使用Python和Flask构建RESTful Web API
23 0