RESTful API 设计最佳实践（2）

最新推荐文章于 2025-08-21 14:30:14 发布

蜗牛lz

最新推荐文章于 2025-08-21 14:30:14 发布

阅读量1k

点赞数

CC 4.0 BY-SA版权

分类专栏：程序/架构设计文章标签： REST RESTfulAPI

本文链接：https://blog.youkuaiyun.com/Linux2_SCDN/article/details/52597765

本文探讨了RESTful API相对于RPC和RMI的优缺点，强调了REST的客户端与服务器耦合度小、开发者友好和资源抽象的优势，同时也指出其学习成本高和接口实现复杂的挑战。

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协议时，