【修真院java小课堂】什么是restful？rest的请求方法有哪些，有什么区别？

背景介绍
 REST是中文翻译为表征状态转移（英文：Representational State Transfer）是Roy Fielding博士在2000年他的博士论文中提出来的一种软件架构风格。

什么是资源？
资源是一种看待服务器的方式，即，将服务器看作是由很多离散的资源组成。每个资源是服务器上一个可命名的抽象概念。因为资源是一个抽象的概念，所以它不仅仅能代表服务器文件系统中的一个文件、数据库中的一张表等等具体的东西，可以将资源设计的要多抽象有多抽象，只要想象力允许而且客户端应用开发者能够理解。与面向对象设计类似，资源是以名词为核心来组织的，首先关注的是名词。一个资源可以由一个或多个URI来标识。URI既是资源的名称，也是资源在Web上的地址。对某个资源感兴趣的客户端应用，可以通过资源的URI与其进行交互。
什么是资源的表述？
资源的表述是一段对于资源在某个特定时刻的状态的描述。可以在客户端-服务器端之间转移（交换）。资源的表述可以有多种格式，例如HTML/XML/JSON/纯文本/图片/视频/音频等等。资源的表述格式可以通过协商机制来确定。请求-响应方向的表述通常使用不同的格式。
什么是状态转移？

：在客户端和服务器端之间转移（transfer）代表资源状态的表述。通过转移和操作资源的表述，来间接实现操作资源的目的。

知识剖析

"本文研究计算机科学两大前沿----软件和网络----的交叉点。长期以来，软件研究主要关注软件设计的分类、设计方法的演化，很少客观地评估不同的设计选择对系统行为的影响。而相反地，网络研究主要关注系统之间通信行为的细节、如何改进特定通信机制的表现，常常忽视了一个事实，那就是改变应用程序的互动风格比改变互动协议，对整体表现有更大的影响。我这篇文章的写作目的，就是想在符合架构原理的前提下，理解和评估以网络为基础的应用软件的架构设计，得到一个功能强、性能好、适宜通信的架构。"
(This dissertation explores a junction on the frontiers of two research disciplines in computer science: software and networking. Software research has long been concerned with the categorization of software designs and the development of design methodologies, but has rarely been able to objectively evaluate the impact of various design choices on system behavior. Networking research, in contrast, is focused on the details of generic communication behavior between systems and improving the performance of particular communication techniques, often ignoring the fact that changing the interaction style of an application can have more impact on performance than the communication protocols used for that interaction. My work is motivated by the desire to understand and evaluate the architectural design of network-based application software through principled use of architectural constraints, thereby obtaining the functional, performance, and social properties desired of an architecture. )

从上面的定义中，我们可以发现REST其实是一种组织Web服务的架构，而并不是我们想象的那样是实现Web服务的一种新的技术，更没有要求一定要使用HTTP。其目标是为了创建具有良好扩展性的分布式系统。
　　反过来，作为一种架构，其提出了一系列架构级约束。这些约束有：
使用客户/服务器模型。客户和服务器之间通过一个统一的接口来互相通讯。
换而言之，通信只能由客户端单方面发起，表现为请求-响应的形式

层次化的系统。在一个REST系统中，客户端并不会固定地与一个服务器打交道。

无状态。在一个REST系统中，服务端并不会保存有关客户的任何状态。也就是说，客户端自身负责用户状态的维持，并在每次发送请求时都需要提供足够的信息。
为REST系统添加这个约束有什么好处呢？主要还是基于集群扩展性的考虑。如果REST服务中记录了用户相关的状态，那么在集群中，这些用户相关的状态就需要及时地在集群中的各个服务器之间同步。对用户状态的同步将会是一个非常棘手的问题：当一个用户的相关状态在一个服务器上发生了更改，那么在什么时候，什么情况下对这些状态进行同步？如果该状态同步是同步进行的，那么同时刷新多个服务器上的用户状态将导致对用户请求的处理变得异常缓慢。如果该同步是异步的，那么用户在发送下一个请求时，其它服务器将可能由于用户状态不同步的原因无法正确地处理用户的请求。除此之外，如果集群进行了不停机的横向扩展，那么用户状态的同步需要如何完成？这些实际上都是非常难以处理的问题。
这样的话服务端和客户端的信息传输量会比较大。

可缓存。REST系统需要能够恰当地缓存请求，以尽量减少服务端和客户端之间的信息传输，以提高性能。

统一的接口。一个REST系统需要使用一个统一的接口来完成子系统之间以及服务与用户之间的交互。这使得REST系统中的各个子系统可以独自完成演化。


我们来看看统一接口这个约束。该约束又包含了四个子约束：
每个资源都拥有一个资源标识。每个资源的资源标识可以用来唯一地标明该资源。
消息的自描述性。在REST系统中所传递的消息需要能够提供自身如何被处理的足够信息。例如该消息所使用的MIME类型，是否可以被缓存等。
资源的自描述性。一个REST系统所返回的资源需要能够描述自身，并提供足够的用于操作该资源的信息，如如何对资源进行添加，删除以及修改等操作。也就是说，一个典型的REST服务不需要额外的文档对如何操作资源进行说明。

HATEOAS。即客户只可以通过服务端所返回各结果中所包含的信息来得到下一步操作所需要的信息，如到底是向哪个URL发送请求等。也就是说，一个典型的REST服务不需要额外的文档标示通过哪些URL访问特定类型的资源，而是通过服务端返回的响应来标示到底能在该资源上执行什么样的操作。一个REST服务的客户端也不需要知道任何有关哪里有什么样的资源这种信息。

如果一个系统满足了上面所列出的五条约束，那么该系统就被称为是RESTful的。

REST密切相关的两个名词：资源和状态。可以说，资源是REST系统的核心概念。所有的设计都会以资源为中心，包括如何对资源进行添加，更新，查找以及修改等。而资源本身则拥有一系列状态。在每次对资源进行添加 ，删除或修改的时候，资源就将从一个状态转移到另外一个状态。

在一个基于HTTP的REST服务中，我们需要使用HTTP请求方法来表示如何对这些资源进行CRUD操作。而在什么情况下到底使用哪个动词则是由这些动词本身在HTTP协议中的意义所决定的。
GET：获取资源。
Post：添加资源。
Put：更新资源。
Delete：删除资源。
但不是一定不変的，put可以新增资源，post也可以更新资源。
怎么选择使用PUT还是POST来创建资源
首先就是如果URL可以在客户端确定，那么就使用PUT，如果是在服务端确定，那么就使用POST，比方说，资源的ID是如何确定的。如果希望客户端在创建资源的时候显式地指定该资源的ID，那么就需要使用PUT。而在由服务端为该资源自动赋予ID的时候，我们就需要在创建资源时使用POST。

另外一个需要考虑的因素则是PUT的等幂性是否对REST系统的设计有所帮助。由于在同一个URI上调用两次PUT所得到的结果相同。因此用户在没有接到PUT请求响应时可以放心地重复发送该响应。这在网络丢包较为严重时是一个非常好的功能。反之，在同一个URI上调用两次POST将可能创建两个独立的子资源。

常见问题

将POST请求转化为put请求和delele请求

解决方案

1、在web.xml文件中配置HiddenHttpMethodFilter过滤器：
 HiddenHttpMethodFilter过滤器可以将POST请求转化为put请求和delete请求
2、在表单域中需要携带一个name值为_method，value值为put或者delete的参数

3、最后在Controller层调用即可。根据@RequestMapping的value值以及携带的参数、请求方式查找匹配函数。

扩展思考

pure RESTful和almost RESTful

pure RESTful和almost RESTful之间的区别主要还是在于一个是理论，一个是工程。在工程中，轻微地违反了一个准则并不一定代表这个解决方案一无是处。而是要看遵守该准则和轻微地违反了该准则之后工作量的大小以及后期的维护成本：之所以提出一系列准则，那是因为遵守该准则拥有一定的好处。如果对该准则的轻微违反可以减少大量的工作量，而且遵守准则的好处并没有消失，或者是通过另一样技术可以快速地重新获得该好处，那么对准则的轻微违反是值得的。

参考文献

https://www.cnblogs.com/loveis715/p/4669091.html
https://zh.wikipedia.org

Spring实战 P426

更多讨论

Q1：get和post的区别。

A1：
1、GET请求的数据会附在URL之后（就是把数据放置在HTTP协议头中），以?分割URL和传输数据，参数之间以&相连，如：getCitycode?lat=100.22&lon=35.33
POST把提交的数据则放置在是HTTP包的包体中。
2、在浏览器上，GET方式提交的数据是有限制的，例如有时候请求的URL太长，会返回错误；但如果是客户端GET请求，是没有数据的限制的。POST没有限制，可传较大量的数据。

Q2：rest的优点。

A2：
可更高效利用缓存来提高响应速度
通讯本身的无状态性可以让不同的服务器的处理一系列请求中的不同请求，提高服务器的扩展性
浏览器即可作为客户端，简化软件需求
相对于其他叠加在HTTP协议之上的机制，REST的软件依赖性更小
不需要额外的资源发现机制
在软件技术演进中的长期的兼容性更好

Q3：在rest风格的架构如何分析登录，复合查询，上万条的数据删除等问题？

A3：

·  login和logout其实只是对session资源的创建和删除； 

·  search本身就是个资源，使用POST创建，如果不需持久化，可以直接在Response中返回结果，如果需要（如翻页、长期缓存等），直接保存搜索结果并303跳转到资源地址就行了； 

·  id多到连url都写不下的请求，应该创建task，用GET返回task状态甚至执行进度；