理解rest风格的接口规范
restfull=representationalstatetransfer即在表现层的状态转移中添加ful形容词后缀表示形容词性
要理解rest风格的结构，理解Representational State Transfer这个短语是最好的方法。 直译就是“表现层的状态变换”，但主语被省略了。 “表现层”实际上是“资源”的“表现层”，通俗地说就是资源在网络中通过某种表现方式进行状态迁移。 分解：
资源：资源或数据。 例如usenames/users/friends/menu/order等； represent ational :使用JSON、XML、JPEG等的某种表现形式State Transfer :状态发生变化。 用HTTP动词实现。
接下来，我们来了解一下具体的rest风格的体系结构——面向资源的体系结构(ROA )。
资源由URI指定。 “internet”是指与internet上的一系列“资源”进行交互并调用其URI。 在对资源的操作中，HTTP协议提供的get (获取网络内某个地址的资源)、post )、put )、patch )、delete )最一般的是获取get和post请求通过的资源。 资源的表示形式为XML或HTML，具体取决于读者是机器还是人、使用web服务的客户软件还是web浏览器。 当然也可以是其他形式。
应用于Web服务并符合restdesign样式的Web API称为rest风格的API。 它由以下三个方面的资源定义：
直观的资源地址： URI，例如http://example.com/resources/每个URI表示一个资源的传输资源： Web服务接收和返回的互联网媒体类型。 例如，JSON、XML、YAML等。 对资源的操作： Web服务支持的一组请求方法。 例如，开机自检、获取、开机自检或删除)。
HTTP请求方法在rest风格的API中的典型应用：
资源GETPUTPOSTDELETE资源组的uri以及该资源组中每个资源的详细信息，例如3http://example.com/resources/listuri (后者是可选的)。 用指定的资源集替换整个当前资源集。 在此组的资源中创建/添加新资源。 此操作经常返回新资源的URL。 删除整个资源组。 各个资源的URI (如3http://example.com/resources/142 )获取指定资源的详细信息。 格式可以通过选择合适的web媒体类型(如XML或JSON )来替换或创建指定的资源。 添加到相应的资源组。 将指定的资源视为资源组，并在该资源组下创建/添加新元素，使其属于当前资源。 删除指定的元素。 REST的误解现在，REST在2000年的时代，似乎确实领先于时代。 Web开发者社区对HTTP的设计意图有很多误解，结果导致了很多HTTP的低效误用。 这种情况一直持续到2005年Web 2.0的兴起。 当时，DCOM、EJB、SOAP/WSDL等DO风格的体系结构，难以满足互联网环境对分布式APP应用体系结构设计的制约，与Web自身的体系结构风格REST相冲突，嵌入Web中所谓的“Web服务”除了基于HTTP的传输协议以外，与(因特网环境中的)真正的Web没有任何关系。
自从Ruby on Rails这个著名的Web开发框架开始大力支持REST开发后，一线的Web开发人员就真正接触到了REST。 但是，Rails支持的REST开发将对资源的操作限定为CRUD (创建、检索、修改和删除)语义。 这意味着将对资源的CRUD操作映射到四个HTTP方法： GET/POST/PUT/DELETE。 这实际上缩小了REST的适用范围。 其他编程语言的Web开发框架，例如Java语言的Struts、Spring MVC等，开始模仿Rails的方式来支持REST开发，结果，第一线的Web开发人员认为REST开发是指get/post
D操作。甚至还有很多仅仅使用了HTTP，而没有使用SOAP的Web服 务API，都自称是REST风格（RESTful）的API。对于什么才是真正的REST风格的误解是如此之多，而将REST作为一个便于营销的 buzzword的挂羊头卖狗肉者也是如此之多，以至于REST的创造者Fielding终于忍无可忍了。2008年10月Fielding写了一篇博 客，做出了一个非常明确的断言：REST APIs must be hypertext-driven!（REST API必须是超文本驱动的！）超文本驱动这个理念变成了一个缩写词HATEOAS，这个缩写词来自于当初Fielding博士论文中的一句话： hypermedia as the engine of application state（将超媒体作为应用状态的引擎）。其实超文本驱动（Hypertext Driven）的理念才是REST架构风格最核心的理念，也是REST风格的架构达到松耦合目标的根本原因。
REST设计进阶当谈及REST成熟度时，一些人常常会引用Richardson所提出来的REST成熟度模型（Maturity Model），并视之为正确的度量方法。
1.在架构中引入资源（Resource）的概念。大多数WS-*服务和POX都只是使用一个URI作为一个服务端口，也只使用一个HTTP方法传输数据。这种做法相当于把HTTP这个应用层协议降级为传输层协议用，《REST实战》也一再强调HTTP是一种应用协议而不是传输协议。再好一点就是使用多个URI，然而不同的URI只是作为不同的调用入口，与此同时只使用同一个HTTP方法传输数据。最常见的错误就是在URI中包含动词，比如URI http://example.com/getOrder?orderId=1234，其实「资源」表示一种实体，所以应该是名词，动词应该放在HTTP协议中。而与此同时URI也有可能破坏HTTP GET的安全性和幕等性，比如某个客户端在http://example.com/updateOrder?id=1234&coffee=latte上执行GET（而不是POST），就能创建一笔新的咖啡订单（一个资源），按理来说GET请求不能改变服务的任何状态。
2.每一个URI代表一种资源，支持HTTP动词（即get，post，put，delete）。此时使用多个URI的话，需要让不同的URI代表不同的资源（注意多个URI可能指向同一个Resource，而一个URI不能指向不同Resource。），同时使用多个HTTP方法操作这些资源，例如使用POST/GET/PUT/DELET分别进行CRUD操作。这时候HTTP头和有效载荷都包含业务逻辑，例如HTTP方法对应CRUD操作，HTTP状态码对应操作结果的状态。我们现在看到的大多数所谓RESTful API做到的也就是这个级别。《REST实战》的译者也谈到：悟性差的人，理解到CRUD式Web服务就满足了。而悟性好的人，可以彻底理解超文本驱动，甚至是与REST关系密切的语义网，最终达到 REST开发的最高境界。