REST风格的优势是什么？
链接：http://www.zhihu.com/question/33959971/answer/57593571
来源：知乎
REST的全称在文章里已经有了，其中的核心是第一个字母R，即资源（Resource）
REST的核心在于，当你设计一个系统的时候，资源是第一位的考虑，你首先从资源的角度进行系统的拆分、设计，而不是像以往一样以操作为角度来进行设计
我们平时搞系统是这样的：
- 有新建用户功能
- 新建用户需要一个URL
- 往这个URL发送的数据要定义好
- 开始写后端和前端
- 操作之间是会有关联，你的设计容易变成“第2个操作要求第1个操作进行过”，这种关系多起来你的系统就乱了
- 你的URL设计会缺乏一致性
- 操作通常被认为是有副作用（Side Effect）的，所以很少有人基于操作去设计缓存之类的东西
- 各个资源虽然可能有关联，但依旧是能够简单地切掉这些关联导致相互独立的，所以不会有非常乱的耦合性
- 对资源的操作就这么几种，所以很容易设计一致的URL
- 我们明白对资源的读操作是无副作用的，所以能玩缓存
但其实现在99%说自己是REST的情况，就是改了个URL风格，用了用PUT和POST，根本没有明白REST是一个什么，也没有按REST的思想来指导设计，在我看来纯粹就是在作秀
要说自己会REST，我觉得至少回答2个问题：
- 对于用户登录和用户退出这两个业务需求，REST指导下的架构和设计如何满足
- 批量的删除、修改、新增如何满足
举例说明，RESTful 到底有哪些好处？
链接：http://www.zhihu.com/question/20130130/answer/14091147
来源：知乎
- 透明性，暴露资源存在。
- 充分利用 HTTP 协议本身语义。
- 无状态，这点非常重要。在调用一个接口（访问、操作资源）的时候，可以不用考虑上下文，也就是对同一个url请求没有上下文关系，不用考虑当前状态，极大的降低了复杂度。举个例子：
比如空调遥控器，你按上下调整温度时，空调温度设定值会变化，遥控器信号到空调是单向传输。
现在空调显示温度20度，遥控器20度。
如果遥控器与空调之间是有状态的，假设你离开空调接收范围调整了遥控器温度，变成19，那回到范围内你按一次升高一度，基于原先温度状态，遥控器给空调发送一个”提高1度“的指令，就会出现遥控器提高到20，而空调变成21。
如果要空间与空调之前是无状态的，假设你离开空调接收范围调整了遥控器温度，变成19，那回到范围内你按一次升高一度，遥控器给空调发送一个”设定温度值20“，这样两者最终还是相同的值。
我家空调是第二种，我觉得这种设计才是合理的。
作者：韦竞杰
链接：http://www.zhihu.com/question/21713929/answer/23970329
来源：知乎
著作权归作者所有，转载请联系作者获得授权。 - HTTP 本身提供了丰富的内容协商手段，无论是缓存，还是资源修改的乐观并发控制，都可以以业务无关的中间件来实现
RESTful的理解
REST（Representational State Transfer ），有中文翻译为"具象状态传输"(也有："代表性状态传输")。是由 Roy Thomas Fielding博士 在2000年就读加州大学欧文分校期间在学术论文中提出的一个术语。他首次系统全面地阐述了REST的架构风格和设计思想。这篇论文是Web发展史上一篇非常重要的技术文献，他也为WEB架构的设计与评判奠定了理论基础。REST 定义了一组体系架构原则，您可以根据这些，包括使用不同语言编写的客户端如何通过 HTTP 处理和传输资源状态。所以在事实上，REST 对 Web的影响非常大，由于其使用相当方便，已经普遍地取代了基于 SOAP 和 WSDL 的接口设计。在多年以后的今天，REST的主要框架已经开始雨后春笋般的出现。个人理解：（一） 首先REST只是一种风格，不是一种标准（二） REST是以资源为中心的（三） REST充分利用或者说极端依赖HTTP协议一．对于今天正在吸引如此多注意力的最纯粹形式的 REST Web 服务，其具体实现应该遵循以下基本设计原则：1.1．显式地使用不同的 HTTP 请求方法1.2．无状态1.3．公开目录结构式的 URI(通过逻辑URI定位资源)。1.1．显式地使用不同的 HTTP 请求方法我们在 Web 应用中处理来自客户端的请求时，通常只考虑 GET 和 POST 这两种 HTTP 请求方法。实际上，HTTP 还有 HEAD、PUT、DELETE 等请求方法。而在 REST 架构中，用不同的 HTTP 请求方法来处理对资源的 CRUD（创建、读取、更新和删除）操作：若要在服务器上创建资源，应该使用 POST 方法。若要检索某个资源，应该使用 GET 方法。若要更改资源状态或对其进行更新，应该使用 PUT 方法。若要删除某个资源，应该使用 DELETE 方法。经过这样的一番扩展，我们对一个资源的 CRUD 操作就可以通过同一个 URI 完成了：读取） [GET] http://www.example.com/photo/logo仍然保持为 [GET] http://www.example.com/photo/logo（创建）http://www.example.com/photo/logo/create改为 [POST] http://www.example.com/photo/logo（更新）http://www.example.com/photo/logo/update改为 [PUT] http://www.example.com/photo/logo（删除）http://www.example.com/photo/logo/delete改为 [DELETE] http://www.example.com/photo/logo从而进一步规范了资源标识的使用。通过 REST 架构，Web 应用程序可以用一致的接口（URI）暴露资源给外部世界，并对资源提供语义一致的操作服务。这对于以资源为中心的 Web 应用来说非常重要。
1.2．无状态在 REST 的定义中，一个 Web 应用总是使用固定的 URI 向外部世界呈现一个资源。它认为Web是由一系列的抽象资源组成，这些抽象的资源具有不同的具体表现形式。譬如，定义一个资源为photo，含义是照片，它的表现形式可以是一个图片，也可以是一个.xml的文件，其中包含一些描述该照片的元素，或是一个html文件。 并且这些具体的表现可以分布在不同的物理位置上。1.3．通过逻辑URI定位资源实现这种级别的可用性的方法之一是定义目录结构式的 URI。此类 URI 具有层次结构，其根为单个路径，从根开始分支的是公开服务的主要方面的子路径。 根据此定义，URI 并不只是斜杠分隔的字符串，而是具有在节点上连接在一起的下级和上级分支的树。例如，在一个收集photo的相册中，您可能定义类似如下的结构化 URI 集合：http://www.example.com/photo/topics/{topic}如：http://www.example.com/photo/topics/home根 / photo之下有一个 /topics 节点。 该节点之下有一系列主题名称，例如生日照片，聚会照片等等，每个主题名称指向某个讨论线。 在此结构中，只需在 {topic}输入某个内容即可容易地收集讨论线程。在某些情况下，指向资源的路径尤其适合于目录式结构。 例如，以按日期进行组织的资源为例，这种资源非常适合于使用层次结构语法。此示例非常直观，因为它基于规则：http://www.example.com/photo/2010/02/22/{topic}第一个路径片段是四个数字的年份，第二个路径片断是两个数字的月份，第三个片段是两个数字的日期。这就是我们追求的简单级别。 在语法的空隙中填入路径部分就大功告成了，因为存在用于组合 URI 的明确模式：http://www.example.com/photo/{year}/{day}/{month}/{topic}从而不需要我们去这样去传递信息：http://www.example.com/photo?year=xxxx&day=xxx$month=xxx&topic=xxxx二．Restful web service的优点：2.1 HTTP头中可见的统一接口和资源地址通过对于HTTP Head 的解析，我们便可以了解到当前所请求的资源和请求的方式。这样做对于一些代理服务器的设置，将带来很高的处理效率。REST 系统中所有的动作和要访问的资源都可以从HTTP和URI中得到，这使得代理服务器、缓存服务器和网关很好地协调工作。而RPC模型的SOAP 要访问的资源仅从 URI无法得知，要调用的方法也无法从HTTP中得知，它们都隐藏在 SOAP 消息中。同样的，在REST系统中的代理服务器还可以通过 HTTP 的动作 (GET 、 POST)来进行控制。2.2 返回一般的XML格式内容一般情况下，一个RESTful Web Service将比一个传统SOAP RPC Web Service占用更少的传输带宽。2.3 安全机制REST使用了简单有效的安全模型。REST中很容易隐藏某个资源，只需不发布它的URI；而在资源上也很容易使用一些安全策略，比如可以在每个 URI 针对 4个通用接口设置权限；再者，以资源为中心的 Web服务是防火墙友好的，因为 GET的 意思就是GET， PUT 的意思就是PUT，管理员可以通过堵塞非GET请求把资源设置为只读的，而现在的基于RPC 模型的 SOAP 一律工作在 HTTP 的 POST上。而使用 SOAP RPC模型，要访问的对象名称藏在方法的参数中，因此需要创建新的安全模型。三． 使用REST架构对于开发人员来说，关心的是如何使用REST架构，这里我们来简单谈谈这个问题。REST带来的不仅仅是一种崭新的架构，它更是带来一种全新的Web开发过程中的思维方式：通过URL来设计系统结构。REST是一套简单的设计原则、一种架构风格（或模式），不是一种具体的标准或架构。到今天REST有很多成功的使用案例，客户端调用也极其方便。下面是我通过Spring3.0来举个例子：public class ArticleController { @RequestMapping(value = "/article/{category}/{id}", method = RequestMethod.GET) public ModelAndView loadArticle(@PathVariable String category, @PathVariable int id, @RequestParam(value = "mode", required = false) String mode) { // ... } @RequestMapping(value = "/article", method = RequestMethod.GET) public ModelAndView loadArticleCategories() { // ... } @RequestMapping(value = "/article", method = RequestMethod.DELETE) public ModelAndView delArticleCategories() { // ... } @RequestMapping(value = "/addarticle", method = RequestMethod.POST) public ModelAndView addArticleCategories(Category category) { // ... } @RequestMapping(value = "/addarticle/{name}", method = RequestMethod.POST) public ModelAndView addArticleCategoriesForName(@PathVariable String name) { // ... } }
然后使用Spring提供的RestTemplate来调用这些服务：
@Component("articleClient") public class ArticleClient { @Autowired protected RestTemplate restTemplate; private final static String articleServiceUrl = "http://localhost:8082/articleservice/"; @SuppressWarnings("unchecked") public List<Category> getCategories() { return restTemplate.getForObject(articleServiceUrl + "article", List.class); } public Article getArticle(String category, int id) { return restTemplate.getForObject(articleServiceUrl + "article/{category}/{id}", Article.class, category, id); } @SuppressWarnings("unchecked") public void delCategories() { restTemplate.delete(articleServiceUrl + "article"); } @SuppressWarnings("unchecked") public List<Category> postCategories() { Map<String, String> params = new HashMap<String, String>(); params.put("name", "jizhong"); return restTemplate.postForObject(articleServiceUrl + "addarticle/{name}", null, List.class, params); } }
提示一下：使用RestTemplate来验证Controller层是一个很不错的选择。需要注意的是：RestTemplate 默认并不支持对 DELETE 方法使用请求体。因为RestTemplate 默认是使用 spring 自身的 SimpleClientHttpRequestFactory 创建请求对象和对其进行相关设置（如请求头、请求体等），它只支持 PUT 和 POST 方法带请求体，RestTemplate 的 DELETE 方法不支持传入请求体是因为 JDK 中 HttpURLConnection 对象的 delete 方法不支持传入请求体（如果对 HttpURLConnection 对象的 delete 方法传入请求体，在运行时会抛出 IOException）。我们可以通过修改 RestTemplate 的 RequestFactory 实现 delete 方法对请求体的支持。具体实现可以参考：http://blog.csdn.net/hemingwang0902/article/details/9152431参考资料：1. 利用 Spring MVC 和 RestTemplate 实现 CorsProxy
深入RESTful无状态原则
前言
在上篇RESTful基础知识中整体的介绍了RESTful架构设计思想的框架，在往后的RESTful主题博文中，我们在这个框架的基础上不断的为其填充更加深入的知识材料。
RESTful基础知识，传送门：http://blog.csdn.net/jmilk/article/details/50452595
无状态原则
Statelessness：无状态原则是RESTful架构设计中一个非常重要的原则，无状态是相对于有状态而言的。在理解什么是无状态的交互请求之前，首先我们需要了解什么是有状态，并对两者进行比较以加深认识。
Web服务的状态
Web服务建立在Web应用程序的协议之上，如：HTTP协议。Web服务的状态指的是请求的状态，而不是资源的状态。是两个关联用户(Client与Server)进行交互操作时所留下来的公共信息(工作流、用户状态信息等数据)。这些信息可以被指定在不同的作用域中，如：page、request、session、application或全局作用域，一般由Server中的Session来保存这些信息。
基于状态的Web服务
在基于状态的Web服务中，Client与Server交互的信息(如：用户登录状态)会保存在Server的Session中。再这样的前提下，Client中的用户请求只能被保存有此用户相关状态信息的服务器所接受和理解，这也就意味着在基于状态的Web系统中的Server无法对用户请求进行负载均衡等自由的调度(一个Client请求只能由一个指定的Server处理)。同时这也会导致另外一个容错性的问题，如果指定的Server在Client的用户发出请求的过程中宕机，那么此用户最近的所有交互操作将无法被转移至别的Server上，即此请求将无效化。
基于无状态的Web服务
在无状态的Web服务中，每一个Web请求都必须是独立的，请求之间是完全分离的。Server没有保存Client的状态信息，所以Client发送的请求必须包含有能够让服务器理解请求的全部信息，包括自己的状态信息。使得一个Client的Web请求能够被任何可用的Server应答，从而将Web系统扩展到大量的Client中。
总结两者的区别
因为无状态原则的特性，让RESTful在分布式系统中得到了广泛的应用，它改善了分布式系统的可见性、可靠性以及可伸缩性，同时有效的降低了Client与Server之间的交互延迟。无状态的请求有利于实现负载均衡，在分布式web系统下，有多个可的Server，每个Server都可以处理Client发送的请求。有状态的请求的状态信息只保存在第一次接收请求的Server上，所以后来同一个Client的请求都只能由这台Server来处理，Server无法自由调度请求。无状态请求则完全没有这个限制。其次，无状态请求有较强的容错性和可伸缩性。如果一台服务器宕机，无状态请求可以透明地交由另一台可用Server来处理，而有状态的请求则会因为存储请求状态信息的Server宕机而承担状态丢失的风险。Restful风格的无状态约束要求Server不保存请求状态，如果确实需要维持用户状态，也应由Client负责。例如：
使用Cookies通过客户端保持登陆状态：
在REST中，每一个对象都是通过URL来表示，对象用户负责将状态信息打包进每一条信息内，保证对象的处理总是无状态的。在HTTP服务器中，服务器没有保存客户端的状态信息，客户端必须每次都带上自己的状态去请求服务器。客户端以URL形式提交的请求包含了cookies等带状态的数据，这些数据完全指定了所需的登录信息，而不需要其他请求的上下文或内存。
传递User credentials是Restful，而传递SessionID是Un-Restful的,因为session信息保存在服务器端。
无状态请求：Server不保存任何请求状态信息，Client的每一个请求都具有User credentials等所需要的全部信息，所以能被任意可用的Server应答。
有状态请求：Server保存了Client的请求状态，Server会通过Client传递的SessionID在Server中的Session作用域找到之前交互的信息，并以此来实现应答。所以Client只能由某一个Server来应答。
转载：http://blog.csdn.net/jmilk/article/details/50461577
对于REST中无状态(stateless)的一点认识(转)
在请求中传递SessionID被普遍认为是unRESTful的，而将用户的credentials包含在每个请求里又是一种非常RESTful的做法。这样一个问题经常会造成困扰。本文就REST的一些概念进行了探讨，解释了REST架构中的状态，无状态（stateless），以及两种状态的区别
今天早上在Yahoo的邮件列表里看到一篇颇有意思的讨论，标题为RESTful vs. unRESTful: Session IDs and Authentication（51CTO编者注：意为REST对非REST，Session ID与验证）。文中让发起讨论的朋友大惑不解的是这样一个问题：为什么在请求中传递SessionID被普遍认为是unRESTful的，而将用户的credentials包含在每个请求里又是一种非常RESTful的做法。看了他接下来对于REST架构风格中"statelessness"属性的理解后，我觉得有必要对这个经常会被人误解词汇以及相关概念做一个简要的整理，希望能够通过这篇随笔解释清楚什么是状态，为什么要实现无状态，以及REST风格架构中的两种状态的区别，最后我会从我的理解出发来回答作者提出的这个问题。
首先，一个Web应用程序协议的“状态”在通常指的是为两个相互关联的用户交互操作保留的某种公共信息，它们常常被用来存储工作流或用户状态信息等数据。这些信息可以被指定不同的作用域如page，request，session或全局作用域，而存储他们的责任也同样可以由Client端或Server端负责。虽然存储状态为企业软件开发带来了诸多便利，但是它也给分布式系统的其他方面带来了许多限制，比如在负载均衡方面，在有状态的模式下，一个用户的请求必须被提交到保存有其相关状态信息的服务器上，否则这些请求可能无法被理解，这也就意味着在此模式下服务器端无法对用户请求进行自由调度。于此相关的另一个问题是容错性，倘若保有用户信息的服务器宕机，那么该用户最近的所有交互操作将无法被透明地移送至备用服务器上，除非该服务器时刻与主服务器同步全部用户的状态信息。此外，由于HTTP本身不是一个有状态的协议，开发人员必须通过模拟实现状态的钝化与激活等。于是为了克服这些不足，无状态(Statelessness)架构风格属性受到了广泛关注。
无状态指的是任意一个Web请求必须完全与其他请求隔离，当请求端提出请求时，请求本身包含了相应端为相应这一请求所需的全部信息。这一约束的出现改善了分布式系统的可见性、可靠性以及可伸缩性，具体的介绍可以参考Roy T. Fielding博士的论文，这里就不哆嗦了。这些从整个系统角度来看无状态似乎过于抽象，那么对于用户来说，怎么感觉的有状态与无状态的差别呢。简单的方法是浏览器的后退按钮，如果一个网站期望用户以A->B->C的流程来交互，而在执行至B时回退的话，那么系统很有可能不是按照其所期望的方式运行，因为用户的状态可能被不可逆地修改了。反过来，搜索引擎（我指的是普通意义上的搜索引擎，而不是根据用户搜索历史个性化了的）是一个无状态架构的范例。任何用户可以在浏览器地址栏中输入http://www.google.com/search?q=RESTful&start=100来获得从第一百条开始的关于RESTful的记录，并且当Google摩洛哥服务器瘫痪时，相关用户请求会被透明地移送至其他服务器。
一切似乎很明了，那么是什么导致了那位朋友的误解呢，答案是RESTful架构对于state的两个不同的解释: 应用状态(Application State)和资源状态(Resource State)。应用状态指的是与某一特定请求相关的状态信息，而资源状态则反映了某一存储在服务器端资源在某一时刻的特定状态，该状态不会因为用户请求而改变，任何用户在同一时刻对该资源的请求都会获得这一状态的表现（Representation）。RESTful架构要求服务器端不保有任何与特定HTTP请求相关的资源，所以应用状态必须由请求方在请求过程中提供。那么再回到那个邮件列表中的问题，为什么传递一个session ID是违背REST架构风格而传递user credentials却不是。我想作者的疑惑源于他没有分清什么是有状态和无状态的架构属性，而认为“传递某种表示状态的信息”到服务器便是“有状态”的表现。其实有状态和无状态与请求本身没有多大关联，重要的是状态信息是由请求方还是响应方负责保存。在Session ID可以被认为是一个用来标识某一会话状态的Key，将其传递给服务器端意味着这样一个请求：“请帮我取出这个状态信息”，也就是说这个请求假设响应方保有着状态信息。由于与某一特定请求相关的状态属于应用状态，而RESTful架构要求任何此类状态由请求方负责提供，所以传递Session ID被认为是unRESTful的做法。反过来，user credential作为一种应用状态，是被期望由请求方提供的，所以在请求中传递user credentials（姑且忽略安全性问题）是符合RESTful架构规范的。
这篇随笔或多或少散发着某种纯粹主义的味道，但我觉得有些概念是值得玩味的。任何一种架构风格的出现都有其期望的，对现有方案的改进或期望克服的问题。作为REST来说，它所期望的是组件的可伸缩性，组件的独立部署，接口统一等特性，而无状态作为实现这组需求的一个特性，个人认为是有必要清楚了解并实际开发过程中落实的。
RESTful 架构中需要分离出 OAuth 服务，将所有的应用认证统一管理，后续的每次请求都需要通过授权服务，再转向到服务器，进行权限管理，这样，就可以将应用的验证状态分离出来，使得后端分布式变为无状态方式，之后的负载或者其他的处理，更加简单，但是，分离出来，架构复杂度提升，维护和开发、测试的成本增加
原文地址：http://developer.51cto.com/art/200906/129424.htm
无状态指的是任意一个Web请求必须完全与其他请求隔离，当请求端提出请求时，请求本身包含了相应端为相应这一请求所需的全部信息。
那么对于用户来说，怎么感觉的有状态与无状态的差别呢。简单的方法是浏览器的后退按钮，如果一个网站期望用户以A->B->C的流程来交互，而在执行至B时回退的话，那么系统很有可能不是按照其所期望的方式运行，因为用户的状态可能被不可逆地修改了。反过来，搜索引擎（我指的是普通意义上的搜索引擎，而不是根据用户搜索历史个性化了的）是一个无状态架构的范例。任何用户可以在浏览器地址栏中输入http://www.google.com/search?q=RESTful&start=100来获得从第一百条开始的关于RESTful的记录，并且当Google摩洛哥服务器瘫痪时，相关用户请求会被透明地移送至其他服务器。
RESTful架构对于state的两个不同的解释: 应用状态(Application State)和资源状态(Resource State)。应用状态指的是与某一特定请求相关的状态信息，而资源状态则反映了某一存储在服务器端资源在某一时刻的特定状态，该状态不会因为用户请求而改变，任何用户在同一时刻对该资源的请求都会获得这一状态的表现（Representation）。RESTful架构要求服务器端不保有任何与特定HTTP请求相关的资源，所以应用状态必须由请求方在请求过程中提供。那么再回到那个邮件列表中的问题，为什么传递一个session ID是违背REST架构风格而传递user credentials却不是。我想作者的疑惑源于他没有分清什么是有状态和无状态的架构属性，而认为“传递某种表示状态的信息”到服务器便是“有状态”的表现。其实有状态和无状态与请求本身没有多大关联，重要的是状态信息是由请求方还是响应方负责保存。在Session ID可以被认为是一个用来标识某一会话状态的Key，将其传递给服务器端意味着这样一个请求：“请帮我取出这个状态信息”，也就是说这个请求假设响应方保有着状态信息。由于与某一特定请求相关的状态属于应用状态，而RESTful架构要求任何此类状态由请求方负责提供，所以传递Session ID被认为是unRESTful的做法。反过来，user credential作为一种应用状态，是被期望由请求方提供的，所以在请求中传递user credentials（姑且忽略安全性问题）是符合RESTful架构规范的。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
