RESTful Api的设计与风格

REST的重要概念 REST全称是Representational State Transfer,中文意思是表征性状态转移。RESTful是指具有REST表征的web架构风格,并非必须遵守的规则。

REST分离了API的结构和逻辑,主要应用于客户端和服务器交互类的软件。基于这种风格设计的软件更加简洁,更有层次,更易于实现缓存等机制。当REST架构的约束条件作为一个整体应用时,将生成一个可以扩展到大量客户端的应用程序。它还降低了客户端和服务器之间的交互延迟。统一界面简化了整个系统架构,改进了子系统之间交互的可见性。REST简化了客户端和服务器的实现,而且对于使用REST开发的应用程序更加容易扩展。

Web 应用程序最重要的 REST 原则是,客户端和服务器之间的交互在请求之间是无状态的。从客户端到服务器的每个请求都必须包含理解请求所必需的信息。如果服务器在请求之间的任何时间点重启,客户端不会得到通知。此外,无状态请求可以由任何可用服务器回答。

另一个重要的 REST 原则是分层系统,分层系统指组件无法了解它与之交互的中间层以外的组件。分层系统限制整个系统的复杂性,保证底层的独立性。 RESTful风格的7种具体特征: 1. 采用URI标识资源 RESTful Web API采用面向资源的架构,所以首先需要考虑的是有哪些资源可供操作。一个资源必须具有一个或者多个标识,在restful中使用URI作为资源的标识。作为资源标识的URI最好具有“可读性”,这用更容易被使用。除此之外,标识资源的URI还应该具有“可寻址性(Addressability)”。也就是说,URI不仅仅指明了被标识资源所在的位置,而且通过这个URI可以直接获取目标资源。(URI具有URL和URN两种主要的表现形式,只有URL具有可寻址性,所以我们最好采用一个URL作为资源的标识。)

2. 使用“链接”关联相关的资源 REST是使用标准的HTTP方法来操作资源的,但仅仅因此就理解成带CURD的Web数据库架构就太过于简单了。这种反模式忽略了一个核心概念:"超媒体即应用状态引擎(hypermedia as the engine of application state)"。 超媒体是什么?当你浏览Web网页时,从一个连接跳到一个页面,再从另一个连接跳到另外一个页面,就是利用了超媒体的概念:把一个个把资源链接起来。要达到这个目的,就要求在表述格式里边加入链接来引导客户端。如使用<a>的href属性关联资源、用url来链接项目所有者和项目地址。

3. 使用统一的接口 统一接口包含了一组受限的预定义的操作,不论什么样的资源,都是通过使用相同的接口进行资源的访问。接口应该使用标准的HTTP方法如GET,PUT和POST,并遵循这些方法的语义。

4. 使用标准的HTTP方法 7个常用的HTTP方法:GET/POST/PUT/DELETE/PATCH/HEAD/OPTIONS。首先GET、HEAD和OPTIONS这三个HTTP方法旨在发请求以获取所需的信息。其他四种(POST、PUT、PATCH和DELETE),旨在针对目标资源作添加、修改和删除操作。具体如下: GET:从服务器取出资源(一项或多项)。 POST:在服务器新建一个资源。 PUT:在服务器更新资源(客户端提供改变后的完整资源)。 PATCH:在服务器更新资源(客户端提供改变的属性)。 DELETE:从服务器删除资源。 HEAD:获取资源的元数据。 OPTIONS:获取信息,关于资源的哪些属性是客户端可以改变的。[旨在发送一种“探测”请求以确定针对某个目标地址的请求须具有怎样的约束,然后根据其约束发送真正的请求。(“跨域资源”的预检 )] 5. 安全性与幂等性 GET、HEAD和OPTIONS均被认为是安全的方法,因为它们旨在实现对数据的获取,其它4个HTTP方法,由于它们会导致服务端资源的变化,所以被认为是不安全的方法。

幂等性在这里是指服务器状态的变化。如果一个方法重复执行多次,产生的效果是一样的,就说该资源是幂等方法 (在网速不够快的情况下,客户端发送一个请求后不能立即得到响应,由于不能确定请求是否被成功提交,所以它有可能会再次发送另一个相同的请求,幂等性决定了第二个请求是否有效。)七种HTTP方法中只有POST是一个非幂等的方法。由于DELETE和PATCH请求操作的是现有的某个资源,所以它们是幂等方法。对于PUT请求,只有在对应资源不存在的情况下服务器才会进行添加操作,否则只作修改操作,所以它也是幂等方法。 因为POST是进行添加操作,如果服务器接收到两次相同的POST操作,将导致两个相同的资源被创建,所以POST是一个非幂等方法。

6. 支持多种资源表示方式 资源和资源表示是两个不同的概念,资源表示是资源的表现形式。对于Web来说,目前具有两种主流的数据结构,XML和JSON,它们也是资源的两种主要的呈现方式。在设计Web API的时候,应该支持不同的资源表示。对于请求提交的资源,我们一般利用请求的Content-Type报头携带的媒体类型来判断其采用的表示类型。对于响应资源表示类型的识别有两种方式,一种是在URI中包含资源标识类型,另一种是采用“内容协商”,根据请求相关报头来判断它所希望的资源表示类型。(比如“Accept”和“Accept-language”报头可以体现请求可以接受的响应媒体类型和语言。)两者的差别是,前者具备浏览器兼容性,后者更智能。

7. 无状态性 RESTful只要维护资源的状态,而不需要维护客户端的状态。对于它来说,每次请求都是全新的,它只需要针对本次请求作相应的操作,不需要将本次请求的相关信息记录下来以便用于后续来自相同客户端请求的处理。

RESTful设计误区: 1. URI中包含动词。因为"资源"表示一种实体,所以应该是名词,URI不应该有动词,动词应该放在HTTP协议中。

2. URI中含有版本号。因为不同的版本,可以理解成同一种资源的不同表现形式,所以应该采用同一个URI。版本号可以在HTTP请求头信息的Accept字段中进行区分

RESTful架构与其他架构的区别 SOAP WebService WebService是一种跨编程语言和跨操作系统平台的远程调用技术。 WebService通过HTTP协议发送请求和接受结果时采用XML格式封装,并增加了一些特定的HTTP消息头,这些特定的HTTP消息头和XML内容格式就是SOAP协议。 效率和易用性 SOAP由于各种需求不断扩充其本身协议的内容,导致在SOAP处理方面的性能有所下降。同时在易用性方面以及学习成本上也有所增加。 RESTful由于其面向资源接口设计以及操作抽象简化了开发者的不良设计,同时也最大限度的利用了HTTP最初的应用协议设计理念。 安全性 RESTful对于资源型服务接口来说很合适,同时特别合适对于效率很高,但是对于安全要求不高的场景。 SOAP的成熟性可以给需要提供给多开发语言的,对于安全性要求比较高的接口设计带来便利。