restful应用场景(restful和rest)
HTTP RESTful规范说明
几个必须的原则:
REST的核心原则是将你的API拆分为逻辑上的资源。这些资源通过http被操作(GET ,POST,PUT,DELETE). 显然从API用户的角度来看，”资源“应该是个名词。即使你的内部数据模型和资源已经有了很好的对应，API设计的时候你仍然不需要把它们一对一的都暴露出来。这里的关键是隐藏内部资源，暴露必需的外部资源。
URL遵循动词+宾语的结构
宾语必须为名词且最好为复数，同时要避免多级URL，可通过参数来展示分类. 使用复数使得URL更加规整, 这让API使用者更加容易理解，对开发者来说也更容易实现.
一旦定义好了要暴露的资源，你可以定义资源上允许的操作，以及这些操作和你的API的对应关系：
可以看出使用REST的好处在于可以充分利用http的强大实现对资源的CURD功能。而这里只需要一个endpoint：/tickets, 再没有其他什么命名规则和url规则了.
如何处理关联？关于如何处理资源之间的管理REST原则也有相关的描述：
其中，如果这种关联和资源独立，那么可以在资源的输出表示中保存相应资源的endpoint。然后API的使用者就可以通过点击链接找到相关的资源。如果关联和资源联系紧密。资源的输出表示就应该直接保存相应资源信息。（例如这里如果message资源是独立存在的，那么上面 GET /tickets/12/messages就会返回相应message的链接；相反的如果message不独立存在，他和ticket依附存在，则上面的API调用返回直接返回message信息）
在API上加入版本信息可以有效的防止用户访问已经更新了的API，同时也能让不同主要版本之间平稳过渡。
版本化API的通常方式有：
这种方式通常在URI中增加一段用于标识版本，例如 /v1 、 /v2 等。例如：
这种方式的优势在于版本信息很容易明显的看出来，可以通过浏览器直接访问。
这种方式的版本信息会放在HTTP的请求头中，通常会利用 Accept 字段，或者自定义一个字段。例如：
这种方式的好处是当版本升级时，URI保持不变，并且仅用于表示资源定位。
版本化的目的是为了标识API的变化，如果API不会变化，或者每次都会重新扩展新的API，这种情况下，就可以标识版本信息。例如：
前面提到了三种版本化API的方式，通常情况下需要针对自己业务的特殊性来挑选其中的一种方式。但是，在实际应用场景中，情况会更加复杂，API的升级通常有两种情况：
因此，折中方案是基于URI中的大版本号和HTTP头中的小版本号整合的方式。下面通过一个简单的示例来解释。
用户管理平台
一个常用的用户管理平台，提供以下API，通过用户ID获取用户信息：
考虑以下两种变动情况：一种是用户id从数字变成了字符串，另一种是新增一个用户头像的值。
前者修改因为数据类型的变化，会导致客户端解析出现问题。因此这样的修改已经破坏了向下兼容性，此时就需要修改API的版本号。例如：
第二种情况，对于旧客户端来说，只是增加了不使用的字段，通常的JSON格式解析库都可以忽略这些不使用的字段。对于新客户端则可以读取新的字段。例如：
这种情况下，基本可以做到向下兼容，因此可以算是“小版本升级”。针对小版本升级，可以将小版本号放到HTTP头中。例如：
由于混合版本化的方式同时涉及到URI和HTTP头字段，前端代理（例如HAProxy、nginx）可以通过这些特定版本号字段将请求代理到对应的后端应用。
例如，前端使用HAProxy进行多版本分发，可以针对URI和HTTP头定制acl，然后再对这些acl进行组合，设置不同的backend。
这样可以将API版本化规则应用到不同的后端，以保证向下兼容性。
基于版本化API规则，将“大版本”应用在URI上，将“小版本”应用在HTTP头字段上。通常来说，如果API升级之后破坏了向下兼容性，就应该升级“大版本”号；如果API升级可以向下兼容，可以升级“小版本”号。
版本化API有很多不同的设计方式，实际应用时，还是要根据业务场景进行选择，包括API版本升级频率，API稳定性等。通过HAProxy、nginx等代理服务，可以在确保向下兼容的情况下，由业务方决定老版本API的保留时间。
URL遵循动词+宾语的结构
API不需要1xx状态码
API 返回的数据格式，不应该是纯文本，而应该是一个 JSON 对象，因为这样才能返回标准的结构化数据。所以服务端返回值的Content-Type属性应为application/json，同时客户端请求头ACCEPT属性应为application/json。
发生错误时，不要返回200状态码，这样相当于状态码失去了意义。应该用状态码表示发生的错误，然后在信息里写明错误详情
提供链接（这个看不懂）
什么是 RESTful 到底 REST 和 SOAP，RPC 有何区别
第一个问题：什么是RESTful？
REST这个词，是Roy Thomas Fielding在他2000年的博士论文中提出的。有兴趣可以看看这里论文`，谁是Fielding?点击前面名字了解。
那RESTful到底是什么呢？简单的讲，它是：一种架构设计风格，提供了设计原则和约束条件，而不是架构。而满足这些约束条件和原则的应用程序或设计就是 RESTful架构或服务。
推荐阅读：
张善友博客——REST 入门介绍
infoq——深入浅出REST
第二个问题：到底 REST 和 SOAP、RPC 有何区别？
这个问题比较大，要知道他们有什么区别首先需要明白，他们分别是什么？
REST上面已经简单的说明了它是什么。
SOAP(简单对象访问协议)是什么？SOAP是一种数据交换协议规范，是一种轻量的、简单的、基于XML的协议的规范。它有什么优点？简单总结为： 易用，灵活，跨语言，跨平台。
易用：是因为它的消息是基于xml并封装成了符合http协议，因此,它符合任何路由器、 防火墙或代理服务器的要求。
灵活：表现在极具拓展性，SOAP 无需中断已有的应用程序, SOAP 客户端、 服务器和协议自身都能发展。而且SOAP 能极好地支持中间介质和层次化的体系结构。
跨语言：soap可以使用任何语言来完成，只要发送正确的soap请求即可。
跨平台：基于soap的服务可以在任何平台无需修改即可正常使用。
RPC(远程调用框架) 是一种允许分布式应用程序调用网络上不同计算机的可用服务的机制。涉猎不多，一下省略256个字。有熟悉的朋友可以在评论补充，然后我会修改到该内容中去
从上面我们可以看出，REST 和 SOAP、RPC 有何区别呢？没什么太大区别，他们的本质都是提供可支持分布式的基础服务，最大的区别在于他们各自的的特点所带来的不同应用场景。
REST可以看着是http协议的一种直接应用，默认基于json作为传输格式，使用简单，学习成本低效率高，~~但是安全性较低~~，而SOAP可以看着是一个重量级的协议，基于xml，SOAP在安全方面是通过使用XML-Security和XML-Signature两个规范组成了WS-Security来实现安全控制的，当前已经得到了各个厂商的支持，.net ，php ，java 都已经对其有了很好的支持 。这是REST薄弱的地方。
webservice和restful的区别
restful是一种架构风格，其核心是面向资源；而webService底层SOAP协议，主要核心是面向活动。
SOAP：简单对象访问协议，很轻量，同时作为应用协议可以基于多种传输协议来传递消息（Http,SMTP等）。
客户端和服务器端的通讯方式
REST 与代理服务器 (Proxy Servers)
一般代理服务器的实现根据 (URI, HTTP Method) 两元组来决定 HTTP 请求的安全合法性。
当发现类似于（{username}，DELETE）这样的请求时，予以拒绝。
对于 SOAP，如果我们想借助于既有的代理服务器进行安全控制.
REST 与缓存服务器 (Cache Server)
使用 HTTP 协议的 SOAP，由于其设计原则上并不像 REST 那样强调与 Web 的工作方式相一致，所以，基于 SOAP 应用很难充分发挥 HTTP 本身的缓存能力,图 7. SOAP 与缓存服务器 (Cache Server)
总结：
REST对于资源型服务接口来说很合适，同时特别适合对于效率要求很高，但是对于安全要求不高的场景。而SOAP的成熟性可以给需要提供给多开发语言的，对于安全性要求较高的接口设计带来便利。所以我觉得纯粹说什么设计模式将会占据主导地位没有什么意义，关键还是看应用场景。
成熟度
SOAP虽然发展到现在已经脱离了初衷，但是对于异构环境服务发布和调用，以及厂商的支持都已经达到了较为成熟的情况。不同平台，开发语言之间通过SOAP来交互的web service都能够较好的互通。
