RPC/webservice/REST/SOA区别联系与对比

先对上面的名词做一个概要介绍&＃xff1a;

1. RPC ,远程过程调用 (面向方法)&＃xff0c;你可以这么理解&＃xff0c;就是在另外一台服务器上有一段代码&＃xff08;函数&＃xff09;&＃xff0c;你可以通过网络远程调用它。用什么协议&＃xff08;http&＃xff0c;tcp&＃xff0c;udp…&＃xff09;&＃xff0c;传输什么数据格式&＃xff08;json&＃xff0c;xml&＃xff0c;二进制…&＃xff09;你都可以自己定义。很简单的概念, 像调用本地服务(方法)一样调用服务器的服务(方法)。
2. SOA ,面向服务的架构(面向消息)&＃xff0c;SOA是一种架构方法&＃xff08;SOA不是Web Service&＃xff0c;Web Service是目前最适合实现SOA的技术。&＃xff09;
3. REST , Representational state transfer远程过程调用 (面向资源)
4. web service顾名思义这是一种提供service的形式&＃xff0c;而且只能通过http&＃xff08;web&＃xff09;来提供service(web service三要素&＃xff1a;SOAP、WSDL(WebServicesDescriptionLanguage)、UDDI(UniversalDescriptionDiscovery andIntegration))
5. SOAP,简单对象访问协议,是一种轻量的、简单的、基于XML&＃xff08;标准通用标记语言下的一个子集&＃xff09;的协议&＃xff0c;它被设计成在WEB上交换结构化的和固化的信息。
6. SOAP和RPC都是web service的实现方式

# Restful
英文全称为 Representational State Transfer&＃xff0c;即表述性状态传递。
1. 面向资源-URL即资源
2. 使用HTTP协议
3. 使用HTTP动词&＃xff08;GET、POST、PUT、DELETE等&＃xff09;来实现资源的添加&＃xff0c;修改&＃xff0c;删除等操作。即通过HTTP动词来实现资源的状态扭转1) GET 用来获取资源&＃xff0c;2) POST 用来新建资源&＃xff08;也可以用于更新资源&＃xff09;&＃xff0c;3) PUT 用来更新资源&＃xff0c;4) DELETE 用来删除资源
4. Server和Client之间传递某资源的一个表现形式&＃xff0c;不限制格式&＃xff0c;xml、json等# RPC
即远程过程调用&＃xff0c;调用远程计算机上的服务&＃xff0c;就像调用本地服务一样。也就是A服务器调用B服务器的方法的过程。
1. 调用原理* 服务消费方&＃xff08;client&＃xff09;调用以本地调用方式调用服务&＃xff1b;* client stub接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体&＃xff1b;* client stub找到服务地址&＃xff0c;并将消息发送到服务端&＃xff1b;* server stub收到消息后进行解码&＃xff1b;* server stub根据解码结果调用本地的服务&＃xff1b;* 本地服务执行并将结果返回给server stub&＃xff1b;* server stub将返回结果打包成消息并发送至消费方&＃xff1b;* client stub接收到消息&＃xff0c;并进行解码&＃xff1b;* 服务消费方得到最终结果。
RPC的目标就是要2~8这些步骤都封装起来&＃xff0c;让用户对这些细节透明。
2. 需要解决的问题* 通讯&＃xff0c;可以使用HTTP、TCP&＃xff08;速度快&＃xff0c;目前框架多是它&＃xff09;* 服务寻址* 序列化&＃xff0c;hession是种系列化组件* 负载均衡

目前的RPC框架

• Hession&＃xff0c;除了hessian协议之外&＃xff0c;还提供了通过servlet方式实现的RPC框架
• Dubbo
• Netty

RPC是以动词为中心的, REST是以名词为中心的, 此处的 动词指的是一些方法, 名词是指资源.

说说几个重要的概念&＃xff1a;

1、REST 是面向资源的&＃xff0c;这个概念非常重要&＃xff0c;而资源是通过 URI 进行暴露。
URI 的设计只要负责把资源通过合理方式暴露出来就可以了。对资源的操作与它无关&＃xff0c;操作是通过 HTTP动词来体现&＃xff0c;所以REST 通过 URI 暴露资源时&＃xff0c;会强调不要在 URI 中出现动词。

比如&＃xff1a;左边是错误的设计&＃xff0c;而右边是正确的

GET /rest/api/getDogs --> GET /rest/api/dogs 获取所有小狗狗
GET /rest/api/addDogs --> POST /rest/api/dogs 添加一个小狗狗
GET /rest/api/editDogs/:dog_id --> PUT /rest/api/dogs/:dog_id 修改一个小狗狗
GET /rest/api/deleteDogs/:dog_id --> DELETE /rest/api/dogs/:dog_id 删除一个小狗狗


左边的这种设计&＃xff0c;很明显不符合REST风格&＃xff0c;上面已经说了&＃xff0c;URI 只负责准确无误的暴露资源&＃xff0c;而 getDogs/addDogs...已经包含了对资源的操作&＃xff0c;这是不对的。相反右边却满足了&＃xff0c;它的操作是使用标准的HTTP动词来体现。

2、REST很好地利用了HTTP本身就有的一些特征&＃xff0c;如HTTP动词、HTTP状态码、HTTP报头等等
REST API 是基于 HTTP的&＃xff0c;所以你的API应该去使用 HTTP的一些标准。这样所有的HTTP客户端&＃xff08;如浏览器&＃xff09;才能够直接理解你的API&＃xff08;当然还有其他好处&＃xff0c;如利于缓存等等&＃xff09;。REST 实际上也非常强调应该利用好 HTTP本来就有的特征&＃xff0c;而不是只把 HTTP当成一个传输层这么简单了。

HTTP动词

GET 获取一个资源
POST 添加一个资源
PUT 修改一个资源
DELETE 删除一个资源


实际上&＃xff0c;这四个动词实际上就对应着增删改查四个操作&＃xff0c;这就利用了HTTP动词来表示对资源的操作。

HTTP状态码

200 OK
400 Bad Request
500 Internal Server Error


在 APP 与 API 的交互当中&＃xff0c;其结果无非就三种状态&＃xff1a;

• 所有事情都按预期正确执行完毕 - 成功
• APP 发生了一些错误 – 客户端错误
• API 发生了一些错误 – 服务器端错误

这三种状态与上面的状态码是一一对应的。

HTTP报头

Authorization 认证报头
Cache-Control 缓存报头
Cnotent-Type 消息体类型报头
......


报头还有很多&＃xff0c;不一一列举。HTTP报头是描述HTTP请求或响应的元数据&＃xff0c;它的作用是客户端 与 服务器端进行相互通信时&＃xff0c;告诉对方应该如何处理本次请求。

3、超媒体
老实说&＃xff0c;这个词汇我到目前还有没搞得全懂。那也说说自己的理解吧&＃xff0c;不一定准确哦&＃xff0c;有错误希望指出。
”超媒体“ 你没听说过没关系&＃xff0c;”超链接“ 你一定不会陌生。简单来说&＃xff0c;”超链接“ 是实现超媒体中的一种方式。”超媒体“希望达到一种就是说在 REST API 中把所有资源给链接起来。它就犹如你打开一个网站的首页&＃xff0c;你难道看到的只有首页吗&＃xff1f;NO !, 不是的&＃xff0c;你可以通过首页查看商品、查看文章、查看论坛。”超媒体“ 就是做这个事情&＃xff0c;它利用 API 把所有资源的关系给链接起来了&＃xff0c;你看到不会只是一个独立的资源&＃xff0c;而是关系网中的一个资源。
”超媒体“ 有点高大上了&＃xff0c;老实说&＃xff0c;就算你够牛X&＃xff0c;写出了一个非常棒的符合”超媒体“的REST API&＃xff0c;你的用户即开发者&＃xff0c;也不一定能够接受你这种高大上的设计。当然&＃xff0c;我相信未来也许可以普及了。

4、最后
上面只是简单说了一些自己最近做REST的一些体验吧。有关于REST的介绍文章实在是太多了&＃xff0c;当然很多写得也非常不错&＃xff0c;我这里 aisuhua/restful-api-design-references · GitHub 收集了一些&＃xff0c;喜欢的话可以看看&＃xff0c;有更好的可以推荐给我。对于上面的回答&＃xff0c;有任何不对&＃xff0c;都希望您能指出&＃xff0c;大家共同进步&＃xff0c;谢谢大家&＃xff01;