虽然REST是无状态的，但它的名字里有状态转移，这让每个人都有点困惑。

无状态

当您在浏览器中打开一个网页时，您将作为服务消费者，www服务器将作为服务提供者为您提供网页。如果是正常连接，客户端和服务器都将执行握手并发起会话（称为TCP连接）。
之后，根据服务器和客户端的行为，状态将更改为ESTABLISHED、IDLE、TIMEOUT等。但在REST中，我们使用的是无状态的HTTP协议，这意味着服务器不会存储任何有关客户端的会话信息。客户端负责发送服务器获得服务所需的所有详细信息。这意味着当我们从服务器调用URIhttp://somedomain:8080/senthil/services/page1时，它具有关于客户端的足够详细信息，可以完全提供page1。

状态转移

使用相同的示例，当您使用某个URL打开网页以查看服务器上的图像文件（RESOURCE）时，www服务器将以某种格式向您（客户端）显示图像，即RESOURCE（图像文件）的REPRESENTATION。
在此过程中，服务器的常量***资源状态***（即，存储在服务器数据库中的图像文件的状态）将以可理解的格式（即，客户端的***应用状态***）表示给客户端。因此，资源状态将相对于客户端保持恒定，并且仅资源的表示将改变，这又将改变应用程序状态。
最后，资源的表示（如何向客户机显示图像）隐式地更改服务器和客户机的状态，称为REST。

表述性状态传输是指传输“表述”。您使用资源的“表述”将服务器上的资源状态传输为客户端上的应用程序状态。

每个对象都有一些状态（数据）和行为（方法）。为了将服务器上的对象在特定时刻的状态传输到客户端，需要某种表示，如JSON或XML或任何其他格式。
所以REST是关于创建对象当前状态的表示，并通过网络传输该表示。

TL;DR

Representational state transfer或简称REST是一个术语，用于以定义明确的格式交换数据，以提高互操作性。通过应用某些约束，应实现从客户端到服务器的解耦，使前者更健壮，后者更灵活地进行更改。
资源表示是应用从资源当前状态到媒体类型的良好定义的语法和结构的Map的结果。因此，它与内容协商高度耦合，内容协商定义了同意媒体类型以将资源状态转换为所请求的表示（=语法和结构）的过程。
REST可以看作是一种在分布式系统中将客户端与服务器/API分离的技术，它使服务器端可以自由地根据需要发展和更改其结构，而不会破坏客户端实现。
为了获得这样一个强大的好处，需要有几个前提条件，因为几乎没有什么是免费的。如果客户端不遵循REST方法，那么服务器就无法实现这样的自由，客户端也无法做到这一点。如果服务器不支持这样的客户端，双方需要遵循同样的原则。如果不严格遵循该方法，则服务器和客户端之间的直接耦合将保持，如果服务器将要改变，则这将导致故障。

• 但实际上如何实现解耦？*

首先，服务器应当通过包括客户端能够使用的URI来支持客户端遵循其任务。使服务器提供客户端能够从客户端所处的当前状态调用的所有URI消除了客户端具有API以及URI是如何构造的先验知识的需要。
第二，客户端不需要解释URI，服务器应返回与链接关系名称组合在一起的URI。即，客户端不应使用如果服务器将上面的URI更改为，例如：http://server.org/api/orders，则它应该使用new-order这样的链接关系。http://server.org/api/new-orders无论出于何种原因，使用链接关系名称的客户端仍将能够遵循其任务，而那些直接使用URI的客户端将需要更新才能继续。
就我所知，还没有定义和记录这种链接关系名称的标准。对于集合链接，关系名称的语义，如self、prev、nextfirst和last看起来足够有意义，尽管诸如order或product-xyz之类更特定于域的内容可能没有意义。这样的语义可以用特殊媒体类型或新标准来描述。
到目前为止，这些观点解决了HATEOAS约束，但不幸的是，这还不是全部。
REST API应该将其几乎所有的描述性工作都花在定义用于表示资源和驱动应用程序状态的媒体类型上，或者花在为现有的标准媒体类型定义扩展关系名称和/或支持超文本的标记上。
菲尔丁进一步评论说：
REST API不应该有对客户端重要的“类型化”资源。规范作者可以使用资源类型来描述接口背后的服务器实现，但这些类型必须是不相关的，对客户端不可见的。对客户端重要的类型只有当前表示的媒体类型和标准化关系名称。
typed resource是客户端具有内容的前提的资源，即，接收到具有链接关系名称user的URI http://server.org/api/user/sam+sample的客户端确定属于该资源的数据描述了人，并且因此可以尝试将资源数据的application/json表示编组为Person对象。
类型化资源的问题在于，客户端具有关于包含在这样的资源中的数据的某些预先分配的假设或知识，虽然一个服务器可以将用户名公开为name属性，但是另一个服务器可以使用firstName和lastName，并且想要服务每个可能性的客户端几乎是不可维护的。此外，如果服务器改变了它的逻辑，客户端可能会有一定的可能性中断。为了对抗这种耦合，应该使用媒体类型来代替。

媒体类型是对表示格式的人类可读文本描述，定义了所使用的语法以及以该格式交换的文档中包含的可用元素的结构和语义。因此，遵循REST体系结构模型的应用程序应该使用established或自定义媒体类型来提高互操作性。与直接耦合客户端和服务器不同，实际上两者都与媒体类型相耦合。2对这些媒体类型的支持可以通过加载现有的库或从头开始实现规范来提供。3如果支持的话，甚至可以通过插件动态加载这些媒体类型。
客户端和服务器应该使用内容协商来商定双方都能理解的通用媒体类型格式，以交换资源的当前状态。（和/或它的一个兄弟），它列出了客户端能够或愿意处理的MIME类型，并且由服务器以包括Content-Type HTTP响应报头的所请求格式之一来响应以通知客户端实际使用了哪个媒体类型表示，或者返回406故障响应。
对于上述的个人示例，客户端可以发送包含以下内容的HTTP Accept报头：application/vcard+json, application/hal+json;q=0.6, application/json;q=0.1到服务器，它要求服务器以由所列出的媒体类型之一定义的语法和结构返回资源的状态。它还指定客户机优选接收根据application/vcard+json媒体类型描述的规范格式化的状态，并且如果服务器不能这样做，则它应当优选hal+json而不是传统的json语法。如果所有请求的媒体类型都是未知的，或者状态不能转换为客户端支持的这种结构或默认表示，则服务器现在或者将当前资源的状态Map到请求的格式之一，或者用适当的406失败消息来响应。
总而言之，REST是一种技术，用于通过依赖定义良好的媒体类型来实现高互操作性，并通过使用内容协商和HATEOAS等功能来将客户端与服务器分离。作为回报，客户端将变得对更改具有鲁棒性，因此总体上需要较少的维护，而服务器则获得能够演进和更改的优势，而不必担心一旦更改，客户端将无法与之交互已上线。
需要首先建立某些事物，如标准化的有意义的链接关系名称、定制的依赖于域的媒体类型以及将状态转换成媒体类型适用表示的Map过程，这是一个不平凡的任务TBH，尽管一旦可用，它们提供了上述益处。

正在从我的blog复制
REST是关于创建对象当前状态（如数据库中的数据）的表示（如JSON或xml或任何其他格式），并通过网络传输该表示。
资源与其表示分离，因此可以以各种格式访问其内容，例如HTML、XML、纯文本、PDF、JPEG、JSON等。关于资源的元数据可用并用于例如控制缓存、检测传输错误、协商适当的表示格式以及执行认证或访问控制
在基本层面上，休息只是一系列原则的集合
1.通信应该是无状态的：服务器不应存储任何状态。如果需要，它应是消息的一部分
1.国家应具有代表性：服务器上的内部资源可以是一种形式，但它应该能够改变它的表示。一个URI引用的对象可以有不同的可用格式。不同的平台需要不同的格式。移动的可能需要JSON，而桌面可能需要XML

1. GET、POST、PUT和DELETE等HTTP动词必须严格遵守。
   1.资源应可寻址：网络上的每个资源都应该有一个特定的地址（特定的URI）

我认为，关于REST架构风格的整个问题，都是围绕着理解而展开的，这是作者罗伊·菲尔丁在他的论文中提出的，一套架构原则，用于构建基于超文本或超媒体范式的架构。
我认为，这个范式是理解这个重要课题的关键。
在Roy Fielding提出的组织客户端-服务器应用程序体系结构的风格背后，我认为有一个现代客户端-服务器应用程序的特定想法，它由一种控制应用程序状态转换的引擎组成，其状态可能是无限可扩展的。
在这个愿景中，Ipertext\Ipermedia是由菲尔丁提出的整个体系结构风格的中心，并且允许这个范例工作的关键概念是“表征（状态）转移”。

我认为“表象”指的是关于“转移”的概念，而不是关于“国家”的概念，也就是说，它是（一种表象类型的）表象转移，在我看来，这是“表象国家转移”名称的主要原因。
因此，在设计Restful应用程序时，首先要设计一个基于组件Web的体系结构，每个组件都在客户端-服务器分层体系结构模型中与其他组件通信，并向每个组件发送其状态的表示。

因此，前端，这个体系结构的第一个客户端，通过它的状态转换，显示由组件发送的状态的呈现，它在一个统一的一致接口上而不是在一个“私有”api上调用认可。

在作者看来，这种类型的应用程序有可能扩展到无限的状态，因为它的状态不依赖于私有API，而是依赖于由该体系结构中的所有代理共享的唯一标识符系统（如URI），依赖于一些动词来管理其状态的转换，并依赖于一致同意的共享表示性传输系统，或加。

此转换以通过组成“public”api的动词将其表示传递给被调用的服务器组件而结束，该api应属于组件客户端-服务器使用的无状态通信协议。
以这种方式，该客户端-服务器组件交互存在于使用无状态协议来交换（传送、通信）组件状态的表示。
让所有这些架构能够无限扩展的核心概念是支持它们架构的表征性转移。

表示是特定资源的不同形式。例如，相同的数据可能被格式化为特定的媒体类型（如XML或JSON），本地化为特定的书面语言或地理区域，和/或压缩或以其他方式编码以进行传输。在每种情况下，基础资源是相同的，但其表示是不同的。

代表性状态转移的含义是REST
RESTful已将DIRECT VERB放入服务器
在实际考虑的例子中，放入VERB的值一般有HTTP GET和POST
SIMPLE协议有很多不像SOAP的地方（有很多复杂的！）
如果回答不满意，请提供更详细的问题
REST有很多讨论的主题，是很多博客和书籍的主题

想象一个状态图--下面的就可以了。

如果这是一组网页，您将从学生的“本科生"登录页开始。根据图表，当您单击“下一步”链接时，它将带您进入“新生"页-假设该学生已经毕业。通过多次单击“下一步”，您将到达最后一页。
当然，也可以有其他的过渡，如“主页”，让您跳转到默认页面。
网站的可见状态与服务器如何在内部实现这种关联无关--这是内部状态。它可能涉及多个数据库、服务器等等。一个学生可能毕业了，他/她的状态可能已经通过其他方法更新了。客户端不知道这些细节--但总是可以期望得到一个连贯的可见状态（集）供人类（或机器）使用。
再举一个例子：当您查看此页面时，您处于StackOverFlow Web层次结构中特定的可识别和可复制的“位置”。
因此，REST风格的状态处理导航。