WEB开发中，使用JSON-RPC好，仍是RESTful API好？

二者没有高下之分，无非是一种约定俗成的标准。习惯用RPC就用RPC，能理解REST就用REST。

JSON-RPC比较符合直观，格式也相对宽松；

REST最近正流行，有本身的一套设计规范。

 

REST面对的疑问跟当年刚开始流行面向对象时的状况是同样的。

它适合不少状况，但并不适合全部状况。

最差的结果就是盲目跟风，又对REST的概念和理念只知其一;不知其二，最后搞出一个半吊子的怪胎，还自我标榜用了流行的RESTful API。

 

REST是一种设计风格，它的不少思惟方式与RPC是彻底冲突的。

RPC的思想是把本地函数映射到API，也就是说一个API对应的是一个function，我本地有一个getAllUsers，远程也能经过某种约定的协议来调用这个getAllUsers。至于这个协议是Socket、是HTTP仍是别的什么并不重要；

RPC中的主体都是动做，是个动词，表示我要作什么。

而REST则否则，它的URL主体是资源，是个名词。并且也仅支持HTTP协议，规定了使用HTTP Method表达本次要作的动做，类型通常也不超过那四五种。这些动做表达了对资源仅有的几种转化方式。

 

这种设计思路是反程序员直觉的，由于在本地业务代码中仍然是一个个的函数，是动做，但表如今接口形式上则彻底是资源的形式。

就像面向对象的「万物皆对象」理论在习惯了纯粹面向过程开发的程序员眼里显得十分别扭同样：个人代码原本就是按顺序、循环、分支这么运行的啊，为啥非得在很明确的结构上封装一层一层的基类子类接口，还要故意给两个函数起同一个名字，调用时才选择用哪个呢？

 

使用「万物皆资源」的思想编写实际项目中的API接口时，最多见的问题就是「这玩意究竟是个什么资源？………………算了，我就直接写吧，无论什么风格了」

• 好比，login和logout应该怎么REST化？
• 好比，多条件复合搜索在GET里写不下怎么办？
• 好比，大量资源的删除难道要写几千个DELETE？

其实在理解了REST后，这些都不是什么无解的难题，只是思惟方式要转换一下：

• login和logout其实只是对session资源的建立和删除；
• search自己就是个资源，使用POST建立，若是不需持久化，能够直接在Response中返回结果，若是须要（如翻页、长期缓存等），直接保存搜索结果并303跳转到资源地址就好了；
• id多到连url都写不下的请求，应该建立task，用GET返回task状态甚至执行进度；

……等等等。

 

若是只是规定了一种规范，却不理解它表相下面的思惟方式，实施中又按照本身的理解随意变更，那结果确定是混乱不堪的。

固然，API怎么写是开发者的自由。但若是一个API在url里放一堆动词、资源设计混乱、各类乱用HTTP Method和Status Code，还自称RESTful API的话，那就像你养了一条狗，还管它叫猫同样。

这种混搭产物，不如叫它REFU吧。

（Remove Extension From Url：从url里去掉文件扩展名）

 

前面说了半天REST的理念和不懂REST形成的问题，可是，这并不表明REST比RPC更「高等」，更不是说不理解REST的人是落伍的。

所谓代码风格、接口形式、各类林林总总的格式规定，其实都是为了在团队内部造成共识、防止我的习惯差别引发的混乱。JSON-RPC固然也是有规范的，但相比REST实在宽松太多了。

若是一个开发团队规定必须在url里写action，全部请求都是POST，能够吗？固然也没问题，只是不要拿出去标榜本身写的是RESTful API就行。

规范最终仍是为了开发者和软件产品服务的，若是它能带来便利、减小混乱，就值得用；反之，若是带来的麻烦比解决的还多，那就犯不上纯粹跟风追流行了。