RESTful API 设计最佳实践（2）

RESTful API 设计最佳实践（2）

常见的分布式应用架构风格有三种：
（1）分布式对象（Distributed Objects）
架构实例：CORBA/RMI/EJB/DCOM/.NET Remoting等。
（2）远程过程调用（RPC）
架构实例：SOAP/XML-RPC/Hessian/Flash AMF/DWR等。
（3）表述性状态转移（REST）
架构实例：HTTP/WebDAV

REST风格架构，被认为是当前WEB Service中最好的架构风格，本章节主要介绍REST风格架构相对于RMI和RPC的好处与不足，更多地是根据本人个人体验。

一、 RPC

RPC的不足：

（1）可扩展性低： RPC的抽象工具是过程，也就是将服务看做是不同过程组成的，这些过程可能会共享一些数据。一个过程通常是对应一个功能，如果想扩展服务，通常需要在协议中添加新的接口，并在服务器端实现。比如已经提供“查询用户a的年龄”接口person-age，若后续需要添加“查询用户性别”，则需要在协议中添加person-sex的接口，并在服务器端新增对它的实现。
（2）客户端与服务器端耦合性较大： 通常客户端和服务器端都要使用配套的封装来实现调用，客户端和服务器端的实现格式固定，修改不灵活。比如有的RPC库的实现存在一些问题：a. 客户端调用全部是同步的方式。b. 服务器端实现比较复杂和难以理解：比如暴露的接口的第一参数必须是username。c. 难以支持数据流/管道的模式实现服务，通常需要使用一个全局变量。比如，为了建立和使用RPC服务，服务器端要用到xxx-rpc库,客户端要用到xxx-rpc-client组件，web客户端用用到则同样要封装的rpc调用。
（3）RPC鼓励的抽象方式可能影响设计灵活和可扩展的API： 在设计RPC的API协议时，通常会像声明一个函数一样，关注其过程名、输入参数、输出，而可能忽略掉服务整体的一个可扩展性和灵活性的考虑。另外，RPC定义出来的一堆接口，可能风格不一致，对开发者使用不够友好。

RPC的优点：

（1）在RPC交互框架已经存在的情况下，RPC开发效率更高，因为只需关注业务本身，基本不用考虑和业务无关的东西，对于客户端调用来说也是如此。
（2）客户端可以像使用本地的过程一样使用RPC服务。

二、 RMI

RMI不足：

（1）扩展性低： RMI的抽象工具是对象，将服务的实现封装在对象内，传输的是对象。其接口是一个interface，通过interface这个类架设起客户端与服务器的桥梁。如果需要添加新的服务功能，需要添加新的接口，则需要修改接口，同时服务端要实现这个接口。
（2）客户端与服务器耦合性特别大： 客户端与服务器端的协议，直接侵入到客户端与服务器端代码。客户端、服务端、协议，捆在了一起。甚至乎有时为了编程便利（偷懒），在定义协议的interface中，还夹杂一些业务实现相关的东西。
（3）对语言依赖高： 通常RMI会绑定某种编程语言（比如java），跨语言实现复杂。比如，如果想在clojure中调用rmi，需要专门写一个转换的库实现将java的类转为本地语言所需的数据结构，若是想在C语言中调用java实现的rmi服务，那应该更难。

RMI的优点：

可以像使用本地对象一样，调用远程对象。

三、REST

REST的优点

（1）客户端与服务器端耦合度小： REST中立于平台和语言。因为使用了http协议、超文本、统一接口等，可以使用任意语言实现REST服务。客户端可以是浏览器、cURL工具、应用程序等。
（2）交互粒度大： REST的消息形式是超文本。
（3）开发者友好性： API易于调试，可以使用浏览器、curl等工具，对于开发者来说非常方便。
（4）抽象工具是资源： 这种抽象方式，可引导设计资源利用灵活，可扩展性强的Web服务。

REST麻烦之处

（1）学习成本： 需要满足REST的规范，就需要了解上述REST的概念，熟悉HTTP协议（比如每个HTTP状态码的意义）。
（2）统一的接口需要更复杂的实现来支持： 需要解析比较复杂的URI，需要仔细甄别返回的状态码应该是http协议中规范的哪一个。

四、后续

上述内容大致介绍了REST服务相关的概念，以及与其他一些服务架构的优劣对比。在下一篇博客中，我将对REST六个约束中的“无状态”进行详细介绍。