摘要：面向服務(wù)面向服務(wù)的基礎(chǔ)面向服務(wù)的三層應(yīng)用層，服務(wù)層，數(shù)據(jù)層應(yīng)用層用于給用戶展示，，，，安卓。在服務(wù)器端，進(jìn)程保持睡眠狀態(tài)直到調(diào)用信息到達(dá)為止。編譯完成，提示我們已經(jīng)在下了。

面向服務(wù)的三層：應(yīng)用層，服務(wù)層，數(shù)據(jù)層

* 應(yīng)用層：用于給用戶展示，PC，H5，IOS，安卓。
* 服務(wù)層：業(yè)務(wù)邏輯，提供接口（商品，訂單，支付，用戶，物流）。
* 數(shù)據(jù)層：提供數(shù)據(jù)支持（mysql, MongoDB, redis, 緩存，文件）。

SOA的目的是什么？

解耦，重用，簡潔

服務(wù)接口設(shè)計(jì)管理

標(biāo)準(zhǔn)化的服務(wù)接口

支持各種消息模式

精確定義的服務(wù)契約

如何判斷一個(gè)軟件是否是建立在真正意義上的SOA架構(gòu)風(fēng)格上的？（是架構(gòu)風(fēng)格而不是架構(gòu)） - 知乎
1.是否做了業(yè)務(wù)組件化，業(yè)務(wù)組件是否和技術(shù)組件分離？

2.系統(tǒng)內(nèi)流程交互是否演化為業(yè)務(wù)組件之間的服務(wù)交互，減少系統(tǒng)內(nèi)業(yè)務(wù)組件之間的強(qiáng)耦合程度。

3.業(yè)務(wù)組件之間的交互是否通過服務(wù)進(jìn)行，即時(shí)當(dāng)前不通過服務(wù)，是否能夠很容易轉(zhuǎn)化為服務(wù)進(jìn)行交互。

4.是否滿足最基本的組件化開發(fā)思路，組件之間相對松散獨(dú)立，可以獨(dú)立部署，可以獨(dú)立進(jìn)行版本管理等。

5.如果軟件存在多個(gè)子系統(tǒng)，子系統(tǒng)之間是否通過總線進(jìn)行集成?

6.是否有專門的代理服務(wù)層或接入服務(wù)，適配器等，方便和外圍系統(tǒng)的集成?
主要考慮幾下幾點(diǎn)：
1、是否將系統(tǒng)劃分為多個(gè)業(yè)務(wù)子系統(tǒng)或模塊；
2、子系統(tǒng)或模塊之間是否是松耦合關(guān)系；
3、有沒有一個(gè)中間件或平臺，將各子系統(tǒng)集成起來。
主要還是業(yè)務(wù)是否組件化，原來也許關(guān)注的是一個(gè)一個(gè)系統(tǒng)，而現(xiàn)在眼中這些系統(tǒng)知識平臺的一些組件，負(fù)責(zé)著某一領(lǐng)域的管理職責(zé)，而更高的業(yè)務(wù)需求是通過組件的協(xié)作完成。業(yè)務(wù)組件可以自由組合，靈活構(gòu)建上層功能，但是自身相對穩(wěn)定，有點(diǎn)面向?qū)ο笤O(shè)計(jì)的感覺，只不過面對的層次更高。

微服務(wù)實(shí)戰(zhàn)：從架構(gòu)到發(fā)布（一） - 力譜宿云 LeapCloud - SegmentFault

微服務(wù)架構(gòu)設(shè)計(jì)

大部分公司并不需要微服務(wù) - SDK.CN - 中國領(lǐng)先的開發(fā)者服務(wù)平臺

REST?RPC?是時(shí)候改變你對微服務(wù)的認(rèn)知了！

微服務(wù)是SOA的更深一步。 隨著互聯(lián)網(wǎng)的發(fā)展，復(fù)雜的平臺、業(yè)務(wù)的出現(xiàn)，導(dǎo)致SOA架構(gòu)向更細(xì)粒度、更通過化程度發(fā)展，就成了所謂的微服務(wù)了。
[](http://www.cnblogs.com/fengzh...
[](http://www.infoq.com/cn/artic...

微服務(wù)強(qiáng)調(diào)一個(gè)去中心化，上述的公司的組織架構(gòu)會被打散，沒有老板，沒有管理層，每一個(gè)人都是一個(gè)服務(wù)，做著自己的事情，
[](https://www.zhihu.com/questio...

微服務(wù)是SOA的升級版，做到更細(xì)的粒度，處理了更多的問題。
例如現(xiàn)在的微服務(wù)都會側(cè)重解決：
服務(wù)發(fā)現(xiàn)、負(fù)載均衡、服務(wù)高可用、分布式請求日志跟蹤

服務(wù)提供了一個(gè)簡單的接口，抽象了底層的復(fù)雜性，然后用戶可以訪問獨(dú)立的服務(wù)，而不需要去了解服務(wù)底層平臺實(shí)現(xiàn)。所以，SOA架構(gòu)的實(shí)現(xiàn)不依賴于技術(shù)，因此，能夠被各種不同的技術(shù)實(shí)現(xiàn)

SOAP, RPC
REST
DCOM
CORBA
OPC-UA
Web services
DDS
Java RMI
WCF (Microsoft"s implementation of web services now forms a part of WCF)
Apache Thrift
SORCER
都是SOA的具體實(shí)現(xiàn)方法而已。

最常用的就是REST，RPC，SOAP三種方法。

一個(gè)虐你千百遍的問題：“RPC好，還是RESTful好？” - 王啟軍 - CSDN博客
http://blog.csdn.net/douliw/a...

RPC是一種進(jìn)程遠(yuǎn)程調(diào)用的方式，更強(qiáng)調(diào)的是異構(gòu)平臺之間進(jìn)程通信的機(jī)制。它可以使用多種協(xié)議（包括HTTP以及其他base在TCP的自定義協(xié)議）和序列化方式（Json/xml/二進(jìn)制），組件之間的耦合度比較高。服務(wù)管理的機(jī)制相對較弱。

RPC就是通過網(wǎng)絡(luò)，調(diào)用遠(yuǎn)程機(jī)器上的方法。

有基于TCP 跟 HTTP的兩種實(shí)現(xiàn)，其原理都是

從tcp或者h(yuǎn)ttp頭部把需要調(diào)用的方法，參數(shù)(包括類型)讀出來，服務(wù)端利用php/java反射，調(diào)用本地的方法。

RPC（Remote Procedure Call Protocol）——遠(yuǎn)程過程調(diào)用協(xié)議，它是一種通過網(wǎng)絡(luò)從遠(yuǎn)程計(jì)算機(jī)程序上請求服務(wù)，而不需要了解底層網(wǎng)絡(luò)技術(shù)的協(xié)議。RPC協(xié)議假定某些傳輸協(xié)議的存在，如TCP或UDP，為通信程序之間攜帶信息數(shù)據(jù)。在OSI網(wǎng)絡(luò)通信模型中，RPC跨越了傳輸層和應(yīng)用層。RPC使得開發(fā)包括網(wǎng)絡(luò)分布式多程序在內(nèi)的應(yīng)用程序更加容易。

RPC采用C/S模式。請求程序就是一個(gè)客戶機(jī)，而服務(wù)提供程序就是一個(gè)服務(wù)器。首先，客戶機(jī)調(diào)用進(jìn)程發(fā)送一個(gè)有進(jìn)程參數(shù)的調(diào)用信息到服務(wù)進(jìn)程，然后等待應(yīng)答信息。在服務(wù)器端，進(jìn)程保持睡眠狀態(tài)直到調(diào)用信息到達(dá)為止。當(dāng)一個(gè)調(diào)用信息到達(dá)，服務(wù)器獲得進(jìn)程參數(shù)，計(jì)算結(jié)果，發(fā)送答復(fù)信息，然后等待下一個(gè)調(diào)用信息，最后，客戶端調(diào)用進(jìn)程接收答復(fù)信息，獲得進(jìn)程結(jié)果，然后調(diào)用執(zhí)行繼續(xù)進(jìn)行。

先回答第一個(gè)問題：什么是RPC框架？ 如果用一句話概括RPC就是：遠(yuǎn)程調(diào)用框架（Remote Procedure Call）
那什么是遠(yuǎn)程調(diào)用？
通常我們調(diào)用一個(gè)PHP中的方法，比如這樣一個(gè)函數(shù)方法: localAdd(10, 20)，localAdd方法的具體實(shí)現(xiàn)要么是用戶自己定義的，要么是php庫函數(shù)中自帶的，也就說在localAdd方法的代碼實(shí)現(xiàn)在本地，它是一個(gè)本地調(diào)用！
遠(yuǎn)程調(diào)用意思就是：被調(diào)用方法的具體實(shí)現(xiàn)不在程序運(yùn)行本地，而是在別的某個(gè)遠(yuǎn)程地方。

比如 A (client) 調(diào)用 B (server) 提供的remoteAdd方法：

1. 首先A與B之間建立一個(gè)TCP連接；

2. 然后A把需要調(diào)用的方法名（這里是remoteAdd）以及方法參數(shù)（10， 20）序列化成字節(jié)流發(fā)送出去；

3. B接受A發(fā)送過來的字節(jié)流，然后反序列化得到目標(biāo)方法名，方法參數(shù)，接著執(zhí)行相應(yīng)的方法調(diào)用（可能是localAdd）并把結(jié)果30返回；

4. A接受遠(yuǎn)程調(diào)用結(jié)果,輸出30。

##遠(yuǎn)程調(diào)用的好處

解耦：當(dāng)server需要對方法內(nèi)實(shí)現(xiàn)修改時(shí)，client完全感知不到，不用做任何變更；這種方式在跨部門，跨公司合作的時(shí)候經(jīng)常用到，并且方法的提供者我們通常稱為：服務(wù)的暴露。

RPC框架就是把我剛才說的這幾點(diǎn)些細(xì)節(jié)給封裝起來，給用戶暴露簡單友好的API使用。

php中流行的rpc框架有哪些
既然php是世界上最好的語言，那php中流行的RPC框架有哪些呢？
先列舉下： phprpc，yar, thrift, gRPC, swoole, hprose
因?yàn)闀r(shí)間和精力有限，不可能一個(gè)一個(gè)的去學(xué)習(xí)和使用，我選幾個(gè)世面上用的最多的幾個(gè)用下吧。因?yàn)镽PC原理是一樣的，都是Client/Server模式，只是每個(gè)框架的使用方式不一樣而已。
主要講解一下 phprpc 和 yar 是我目前聽說和接觸最多的了。
phprpc先從官網(wǎng)下載最新穩(wěn)定版的phprpc:下載鏈接 解壓。
安裝我們會發(fā)現(xiàn)里面有很多文件和文件夾，結(jié)構(gòu)如下：

* dhparams/
* pecl/
* bigint.php
* compat.php
* phprpc_date.php
* xxtea.php
* dhparams.php
* phprpc_server.php
* phprpc_client.php

其中有dhparams和pecl是文件夾，pecl中的是php的xxtea擴(kuò)展，按照官網(wǎng)的描述，可以安裝也可以不安裝，不安裝phprpc也是可以運(yùn)行的。但是如果你需要更快的加密處理能力，可以安裝下。
我還是安裝吧。畢竟加密能力更快，是好事：
安裝步驟如下，先將pecl下的xxtea文件夾復(fù)制到php源碼的etx目錄：/lamp/php-5.4.11/ext下。然后用phpize進(jìn)行擴(kuò)展重新編譯。

1. [root@localhost /]# cd /lamp/php-5.4.11/ext/xxtea
2. [root@localhost xxtea]# /usr/local/php/bin/phpize
3. [root@localhost xxtea]# ./configure --enable-xxtea=shared --with-php-config=/usr/local/php/bin/php-config
4. make && make install

OK ,編譯完成，提示我們xxtea.so已經(jīng)在/usr/local/php/lib/php/extensions/no-debug-zts-20100525/xxtea.so 下了。
下面，我們就需要在php.ini的最后將這個(gè)xxtea.so加上：
[root@localhost /]# vi /usr/local/php/etc/php.ini

[xxtea]
extension=xxtea.so

好。加好了后，我們需要重啟下apache或者php-fpm
重啟apache
[root@localhost /]# /usr/local/apache/bin/apachectl restart

平滑重啟php-fpm
kill -USR2 cat /usr/local/php/var/run/php-fpm.pid

重啟完畢后，打開phpinfo()頁面，搜索一下，應(yīng)該就能夠看到xxtea了。
開始使用先來個(gè)簡單的例子，phprpc也是分為服務(wù)器端和客戶端的。所以文件夾中對應(yīng)的就是phprpc_server.php 和 phprpc_client.php
我們參考官網(wǎng)的幾個(gè)例子，練習(xí)下：
server.php 服務(wù)端：這樣寫就完成了一個(gè)最簡單的helloword的接口。

1. add("HelloWorld");
8. $server->start();

運(yùn)行下server.php，我擦，居然報(bào)錯(cuò)了?。?！
PHP Strict Standards: Non-static method PHPRPC_Server::initSession()....
Cannot redeclare gzdecode().....

google了下，說是先把 phprpc_server.php的413行的initSession()改成static function
static function initSession() {

****

}

PS. 我了個(gè)擦，這么大的錯(cuò)誤，phprpc是怎么發(fā)布的?。?！
在把compat.php 的第 71行的 gzdecode()函數(shù)，php5.4已經(jīng)實(shí)現(xiàn)了這個(gè)函數(shù)了。這樣函數(shù)就被重寫了，就報(bào)錯(cuò)了，所以加個(gè)判斷：
if (!function_exists("gzdecode")) {

//將gzdecode函數(shù)包括進(jìn)來

}

好。改完，保存。再運(yùn)行下server.php 。ok 了。不報(bào)錯(cuò)了。輸出：
phprpc_functions="YToxOntpOjA7czo5OiJoZWxsb3dvcmQiO30=";

我們接下來寫客戶端 client.php, 看是如何寫的？

1. HelloWorld();
5. ?>

我們在執(zhí)行以下client.php，如愿以償?shù)妮敵隽耍?br>Hello Word!

這樣一個(gè)簡單的Server/Clent交付就搞定了。雖然中間出了點(diǎn)差錯(cuò)，但是總體來說還是蠻簡單易懂的!
其他的更高級的用法可以參考官網(wǎng)的。
yaryar 是國內(nèi)著名的php大神鳥哥惠新宸的大作，在微博產(chǎn)品中已經(jīng)開始使用。它也是一款rpc框架。它由于使用純C編寫的用于php的擴(kuò)展，所以，效率應(yīng)該是蠻高的，而且支持異步并行，這點(diǎn)還是贊的。
下載安裝官網(wǎng)下載：http://pecl.php.net/package/yar 最新的版本 yar-1.2.4.tgz
然后解壓復(fù)制到php源碼的etx目錄：/lamp/php-5.4.11/ext下。然后用phpize進(jìn)行擴(kuò)展重新編譯。

1. [root@localhost yar-1.2.4]# /usr/local/php/bin/phpize
2. [root@localhost yar-1.2.4]# ./configure --with-php-config=/usr/local/php/bin/php-config

但是出現(xiàn)了點(diǎn)問題：提示，curl 有問題：
configure: error: Please reinstall the libcurl distribution - easy.h should be in /include/curl/

估計(jì)是我本機(jī)curl 有問題，那用yum 安裝一下吧：
yum -y install curl-devel

安裝完成curl 后繼續(xù)編譯安裝，就沒啥問題了：

1. [root@localhost yar-1.2.4]# /usr/local/php/bin/phpize
2. [root@localhost yar-1.2.4]# ./configure --with-php-config=/usr/local/php/bin/php-config
3. [root@localhost yar-1.2.4]# make && make install

成功之后，提示我們 yar.so 擴(kuò)展在已經(jīng)在/usr/local/php/lib/php/extensions/no-debug-zts-20100525/ 下了。
我們vi編輯一下 php.ini ,最后面加上yar.so擴(kuò)展，然后重啟一下 apache 或者php-pfm就可以了。
[root@localhost /]# vi /usr/local/php/etc/php.ini

[yar]
extension=yar.so

好。加好了后，我們需要重啟下apache或者php-fpm
重啟apache
[root@localhost /]# /usr/local/apache/bin/apachectl restart

平滑重啟php-fpm
kill -USR2 cat /usr/local/php/var/run/php-fpm.pid

重啟完畢后，打開phpinfo()頁面，搜索一下，應(yīng)該就能夠看到y(tǒng)ar了。
開始使用和其他的rpc框架一樣，yar也是server/client模式，所以，我們也一樣，開始寫一個(gè)簡單的例子來說下如何調(diào)用。
yar_server.php表示服務(wù)器端

     handle();

好，我們在瀏覽器里運(yùn)行一下，就會出現(xiàn)如下圖所示的輸出。很高端?。。。▲B哥說這樣做的用途是可以一目了然的知道我這個(gè)rpc提供了多少接口，把a(bǔ)pi文檔都可以省略了。

好，我們開始寫yar_client.php 這個(gè)是客戶端：

     $client = new Yar_Client("http://127.0.0.1/yar_server.php");
     echo $client->api("helo word");

好，像其他的 swoole，hprose等基本都是這個(gè)原理，只是看誰的功能更加，用起來更順手罷了。

SOAP可支持任何傳輸協(xié)議，從HTTP/HTTPS到SMTP（Simple Mail Transfer Protocol，簡單郵件傳送協(xié)議），甚至JMS（Java Messaging Service，Java消息傳遞服務(wù)）。不過，由于XML較為冗長且解析費(fèi)時(shí)，因此采用XML也成為一個(gè)弊端。
SOAP的使用場景：異步處理與調(diào)用，有狀態(tài)的操作，數(shù)據(jù)格式必須一致。
SOAP是基于HTTP和XML的實(shí)現(xiàn)，因此會更容易做業(yè)務(wù)隔離，在系統(tǒng)可維護(hù)性和可擴(kuò)展性上優(yōu)于RPC。
簡單來說： SOAP = HTTP+XML+RPC

對于PRC的概念不太清楚，貌似在.NET中接觸到的也不太多，就說說SOAP和REST吧。

SOAP和REST嚴(yán)格來說不是兩個(gè)對等的概念，姑且理解成兩種服務(wù)設(shè)計(jì)思想和及其具體的實(shí)現(xiàn)架構(gòu)吧。

正如前文有大?；卮鸬?，二者各有自己的使用場景。如果創(chuàng)建的分布式服務(wù)要求較好的安全性，對于傳輸?shù)鹊讓訉?shí)現(xiàn)要求較強(qiáng)的可定制性，可以考慮SOAP；如果要求設(shè)計(jì)實(shí)現(xiàn)簡單，一般來說安全性要求不高可以考慮REST。這只是一般情況，但偏于面向資源的服務(wù)使用REST有天然的優(yōu)勢。

就我們的項(xiàng)目來說，SOAP在.NET中現(xiàn)在經(jīng)常使用WCF框架，而RESTful則多使用Web API。WCF中雖然也有RESTful實(shí)現(xiàn)，但并不好用。

SOAP(簡單對象訪問協(xié)議)是什么？SOAP是一種數(shù)據(jù)交換協(xié)議規(guī)范，是一種輕量的、簡單的、基于XML的協(xié)議的規(guī)范。它有什么優(yōu)點(diǎn)？簡單總結(jié)為： 易用，靈活，跨語言，跨平臺。
易用：是因?yàn)樗南⑹腔趚ml并封裝成了符合http協(xié)議，因此,它符合任何路由器、 防火墻或代理服務(wù)器的要求。
靈活：表現(xiàn)在極具拓展性，SOAP 無需中斷已有的應(yīng)用程序, SOAP 客戶端、 服務(wù)器和協(xié)議自身都能發(fā)展。而且SOAP 能極好地支持中間介質(zhì)和層次化的體系結(jié)構(gòu)。
跨語言：soap可以使用任何語言來完成，只要發(fā)送正確的soap請求即可。
跨平臺：基于soap的服務(wù)可以在任何平臺無需修改即可正常使用。

REST可以看著是http協(xié)議的一種直接應(yīng)用，默認(rèn)基于json作為傳輸格式，使用簡單，學(xué)習(xí)成本低效率高，但是安全性較低，而SOAP可以看著是一個(gè)重量級的協(xié)議，基于xml，SOAP在安全方面是通過使用XML-Security和XML-Signature兩個(gè)規(guī)范組成了WS-Security來實(shí)現(xiàn)安全控制的，當(dāng)前已經(jīng)得到了各個(gè)廠商的支持，.net ，php ，java 都已經(jīng)對其有了很好的支持 。這是REST薄弱的地方

接口調(diào)用通常包含兩個(gè)部分，序列化和通信協(xié)議。常見的序列化協(xié)議包括json、xml、hession、protobuf、thrift、text、bytes等；通信比較流行的是http、soap、websockect，RPC通?；赥CP實(shí)現(xiàn)，常用框架例如netty。

RESTful通常采用http+JSON實(shí)現(xiàn)。

JSON-RPC是指通信協(xié)議采用二進(jìn)制方式，而不是http，序列化采用JSON的形式。

http vs 高性能二進(jìn)制協(xié)議

http相對更規(guī)范，更標(biāo)準(zhǔn)，更通用，無論哪種語言都支持http協(xié)議。如果你是對外開放API，例如開放平臺，外部的編程語言多種多樣，你無法拒絕對每種語言的支持，相應(yīng)的，如果采用http，無疑在你實(shí)現(xiàn)SDK之前，支持了所有語言，所以，現(xiàn)在開源中間件，基本最先支持的幾個(gè)協(xié)議都包含RESTful。但是，由于受限于HTTP協(xié)議，需要帶HTTP請求頭，導(dǎo)致傳輸起來效率或者說安全性不如RPC。
RPC協(xié)議性能要高的多，例如Protobuf、Thrift、Kyro等，（如果算上序列化）吞吐量大概能達(dá)到http的二倍。響應(yīng)時(shí)間也更為出色。千萬不要小看這點(diǎn)性能損耗，公認(rèn)的，微服務(wù)做的比較好的，例如，netflix、阿里，曾經(jīng)都傳出過為了提升性能而合并服務(wù)。如果是交付型的項(xiàng)目，性能更為重要，因?yàn)槟阗u給客戶往往靠的就是性能上微弱的優(yōu)勢。

RPC的應(yīng)用場景：大型分布式開發(fā)。使用socket來通信，其目的就是更快更安全，但是相對的，略有開發(fā)難度。
而RPC是基于TCP或自定義協(xié)議實(shí)現(xiàn)的不同，性能會略高于到遠(yuǎn)高于REST不等，但是異構(gòu)系統(tǒng)間的耦合度會更高，間接增加系統(tǒng)的故障率和排錯(cuò)難度。
對于RPC本身可以走HTTP ,TCP等不同的協(xié)議，比如淘寶的Dubbo框架，RPC是可以選擇走TCP協(xié)議還是走HTTP協(xié)議的。

簡單來說成熟的rpc庫相對http容器，跟多的是封裝了“服務(wù)發(fā)現(xiàn)”，”錯(cuò)誤重試“，“注冊中心”，有豐富的監(jiān)控管理，發(fā)布，下線接口，動態(tài)擴(kuò)展等，一類面向服務(wù)的高級特性。可以這么理解，rpc框架是面向服務(wù)的更高級的封裝。如果把一個(gè)http server容器上封裝一層服務(wù)發(fā)現(xiàn)和函數(shù)代理調(diào)用，那它就已經(jīng)可以做一個(gè)rpc框架了。

所以為什么要用rpc調(diào)用？

因?yàn)榱己玫膔pc調(diào)用是面向服務(wù)的封裝，針對服務(wù)的可用性和效率等都做了優(yōu)化。單純使用http調(diào)用則缺少了這些特性。

基于以上兩點(diǎn)，性能和封裝的考量下，REST只適用于業(yè)務(wù)比較簡單的場景。所以，（但是，場景是否簡單也是相對的，RPC適用于真正大型的分布式開發(fā)。）

REST目前基于HTTP/HTTPS；使用HTTP來通信，是個(gè)不錯(cuò)的方案。因?yàn)槟壳按蟛糠终Z言的標(biāo)準(zhǔn)庫都是支持HTTP的，而且HTTP這種無狀態(tài)的請求，更容易接受。同時(shí)套用了HTTP定義的動詞和狀態(tài)碼，更容易接受。實(shí)現(xiàn)起來較RPC框架使用的socket通信而言，也更簡單一些。

REST的使用場景：有限的帶寬和資源，無狀態(tài)的CURD操作，緩存考慮（利用無狀態(tài)操作的特性，使得信息可以被緩存，REST是很好的選擇）

REST的優(yōu)點(diǎn)是套用了HTTP那一套狀態(tài)碼和動詞，很方便。但是相應(yīng)的，套用了HTTP的，也造成了對于開發(fā)者的困擾。

所有的接口，服務(wù)器端原本就存在有相應(yīng)的函數(shù)，它們本來就有自身的命名空間，接受的參數(shù)、返回值、異常等等。
采用輕便的方式暴露出來即可。
無需把一堆函數(shù)重新歸納到“資源”，再削減腦袋把所有的操作都映射為“增刪改查”。
對應(yīng)到web上，rpc的成熟方案非常多，有古老的soap，也有輕量的json rpc。
RESTful使用了HTTP的4xx，5xx的那些錯(cuò)誤定義。相當(dāng)于HTTP定義了這些錯(cuò)誤，供開發(fā)者識別。
但實(shí)際上，業(yè)務(wù)肯定會自己定義錯(cuò)誤標(biāo)示。那么，你不覺得那些編號反而會有干擾。不知道的還以為是網(wǎng)絡(luò)連接有問題，沒想到只是請求錯(cuò)誤。