我们的专业付出，值得您的永久信赖！为您量身定制，信誉第一！

本文是「架构气势派头：你真的懂REST吗？」的增补！REST全称是Representational State Transfer，现在普遍接受的中文翻译为「表述性状态转移」！纵然翻译过来了，你依然有一堆疑问：什么是「表述性」的？什么是状态？什么是转移？转移的是什么？所以本文试图回覆如下几个问题：为什么要叫REST这个名字?什么是状态、资源、表述？以及它们之间有什么关系？什么是转移(Transfer)、变迁(transitions)？转移什么？变迁什么？为什么叫REST?为什么Fielding博士要取这么个难以明白的名字呢？其实REST论文的第六章给出了明确的谜底：REST was originally referred to as the "HTTP object model," but that name would often lead to misinterpretation of it as the implementation model of an HTTP server. The name "Representational State Transfer" is intended to evoke an image of how a well-designed Web application behaves: a network of web pages (a virtual state-machine), where the user progresses through the application by selecting links (state transitions), resulting in the next page (representing the next state of the application) being transferred to the user and rendered for their use. REST原来是想叫「HTTP object model」的，可是这个名字会给人误解，让人误以为REST是一个HTTP服务器的实现。叫REST这个名字的目的是为了表示一个「设计良好的Web应用」应该有怎样的行为：一个由web页面组成的网（一个虚拟状态机），用户通过选择链接在应用中前进（状态变迁），用户的选择会导致下一个页面（代表应用的下一个状态）被转移到用户端、并被渲染出来以供使用！Tips：注意上面括号里的单词(state transitions)，这里是transitions而不是transfer。transitions表现的是过渡、切换、变迁，好比场景的切换，就是从一个场景到了另一个场景。

这里是从一个状态切换到了另一个状态。REST中文文档里，还是将其翻译成了「转移」，应该是不正确的！网上许多讨论REST的文章或帖子，关注的点有两个：Representational应该怎么翻译？是「表述」还是「表述性」Transfer应该怎么翻译？是「转移」还是「传输」而从上面这段话，你会发现，重点既不是Representational、也不是Transfer，而是State！你有没有以为上面所提到的State和你平时所明白的State有差异？或者说比力违和？我们都知道，要保证服务端的伸缩性，就要确保服务端是无状态的！如果是「无状态」的，那么为什么有「状态的变迁」呢？岂非REST没有伸缩性？显然不是，要知道，Web可是现今伸缩性最好的系统！所以这里所指的State与我们平时所说的State不是一个观点！这里的State是「应用状态」，我们所说的State是「资源状态」(这里所说的资源和REST中所指的资源也是纷歧样的，下面会说到)！先说应用状态，在上文中，可以看到。应用状态指的是一个个的Web页面！Web页面上有链接，你点击链接后，这个链接所对应的「应用状态」会从服务器「转移」到客户端，渲染出来，展示给你。

你就「切换」到了下一个「应用状态」！所以「State Transfer」指的是：「应用状态」从服务端「转移」到了客户端，导致客户端的「应用状态」从当前状态「变迁」到了下一个状态！资源与表述在解释「资源状态」之前，要先来解释一下什么是「资源」？什么是「表述」？早期URI设计时，「资源」表现的是「文档」！它假设万维网里转移的都是文档！现在看来，显然不是！REST对「资源」举行了抽象！一般我们对资源的明白是「可以在万维网里转移的任何内容」，好比：网页、图片、视频等！但实际上，REST论文中给出的界说和我们平常所明白的「资源」差异还是很大的！REST论文中给出的解释：The resource is not the storage object. The resource is not a mechanism that the server uses to handle the storage object. The resource is a conceptual mapping -- the server receives the identifier (which identifies the mapping) and applies it to its current mapping implementation (usually a combination of collection-specific deep tree traversal and/or hash tables) to find the currently responsible handler implementation and the handler implementation then selects the appropriate action+response based on the request content. 资源不是存储工具！也不是服务器处置惩罚存储工具的机制！资源是一个观点上的映射关系：服务器吸收到标示符（这些标示符标示了这个映射关系），将其应用到当前的映射实现上（一般是特定荟萃【深度遍历的树和/或哈希表】的组合）来找到当前卖力处置惩罚该请求的处置惩罚器、这个处置惩罚凭据请求内容选择合适的行动+响应我用一段伪代码来解释一下！var mappingImpl = {'/pathA':handlerA,'/pathB':handlerB,'/pathC':handleC,...}mappingImpl.get('/pathB').handle(req);mappingImpl就是映射实现，包罗了所有URI随处理器实现的映射关系！'/pathB':handlerB这个映射关系就是「资源」！mappingImpl.get('/pathB')就是凭据URI获取到卖力处置惩罚该请求的处置惩罚器handle(req)就是凭据请求内容来选择合适的行动+响应根据这个界说的话，实际上REST中所指的「资源」和我们平常所指的「资源」基础不是同一个工具：REST中的资源指的是URI到针对这个URI的处置惩罚器之间的映射关系我们平常所指的资源，对应到REST中实际上是这个处置惩罚器处置惩罚后的返回效果你会发现，REST中的资源是个「动态」的工具，而我们所说的资源是个「静态」的工具，或者说就是个类型多样化的「文档」而已！用伪代码表现的话就是：var resourceMap = {'/pathA':resourceA,'/pathB':resourceB,'/pathC':resourceC,...}resourceMap.get('/pathB');实际上，现代Web应用中，绝大部门URI标示的都是动态的内容！所以在这一点上，REST对资源的界说越发的准确！你可能会说，这两者的区别可能不是那么大，因为无论资源指的是关系还是处置惩罚效果，我们最终都是看到的是一样的内容！你确定吗？假设资源就是我们平常所明白的「返回效果」：上面说到的，返回内容中包罗了链接，客户端可以通过链接变迁到下一个状态，链接和资源怎么同时返回？如果URI指定的谁人资源不存在的话，应该返回什么呢？resourceMap.getOrDefault('/pathD','这里该返回什么？');返回「空资源」？那什么是「空资源」，如何表现「空资源」？null吗？那客户端又如那边理这个特殊的null呢？或者说是一个「Null资源」？「Null资源」是资源吗？既然是没有资源，那还叫资源吗？是不是很拗口？REST通过表述来解决这个问题：表述就是处置惩罚器返回的效果包罗了链接（操作）和内容（响应）如果没有内容，那么返回的就是一个没有内容的表述mappingImpl.getOrDefault('/pathD',defaultHandler).handle(req); // 如果找不到对应的处置惩罚器就用默认处置惩罚器处置惩罚。//如果找不到请求内容对应的响应，就返回一个没有内容的表述上面所说的Web页面就是一种表述，也就是说表述是「应用状态」！所以对REST的明白应该是：通过链接，以表述的方式，将应用状态从服务端转移到客户端！解释完资源和表述，最厥后解释一下「资源状态」！资源状态许多关于RESTful的博文，主要讲的是：URI要怎么设计要用POST建立资源要用PUT更新资源要用DELETE删除资源要用GET获取资源以User为例:GET /users // 获取用户列表GET /user/1 // 获取ID为1的用户信息POST /user // 建立用户PUT /user/1 // 更新ID为1的用户信息DELETE /user/1 // 删除ID为1的用户信息这里的POST,PUT,DELETE改变的是「资源状态」！和上面所说的「应用状态」是两回事！许多地方都没有明确的区离开来！记恰当初看JVM的时候，也有类似的情况！JVM中有三个栈，虚拟机栈、操作数栈和当地方法栈。许多地方都直接叫做栈，这就导致了明白的杂乱！前面说一个方法的挪用就是将对应的栈帧入栈；后面又说指令的执行，对应的操作数入栈。

实际上前一个栈指的是虚拟机栈，后一个栈指的是操作数栈！在这里情况类似，状态没有区离开，也会导致明白的杂乱！前面说「状态的转移」，这里又说「状态的改变」！一个是「应用状态的转移」，一个是「资源状态的改变」！如果根据上面临资源的明白的话，这里的状态其实不应该叫「资源状态」，而应该是「内容状态」！REST完整流程下面以User的CRUD为例，来说明一下REST的完整流程：会见/users链接，服务端找到该URI对应的处置惩罚器，对请求举行处置惩罚，将包罗了User列表内容的表述转移到客户端客户端展示该表述。表述中包罗了到新增User页面的链接、到编辑User页面的链接、删除User的链接等操作链接用户点击到新增User页面的链接，服务端转移新增User的表述。客户端「应用状态」变迁到新增User页面用户填写信息，点击提交按钮。

服务器处置惩罚该请求，将一条新的用户信息添加到数据库，导致了User「内容状态」变化。同时将新的包罗了User列表内容的表述转移到客户端客户端「应用状态」又进入到了User列表页面......参考资料Architectural Styles and the Design of Network-based Software Architectures。

本文来源：云开体育app，云开app手机版下载，云开体育app官网下载，云开体育官方网站-www.szjmccc.com