RESTful API教程：学习关键的Web服务设计原则

本文为翻译发表，转载需要注明来自公众号EAWorld。

作者：Cameron McKenzie

译者：白小白

原题：RESTful APIs tutorial: Learn key web service design principles

全文2722字，阅读约需要10分钟

白小白****：

原文地址另附有一个本文的视频讲解，作者语音清晰，风趣幽默（关于幂等这个词的读音，作者并不十分确定，并对自己进行了调侃，2333），详细内容可点击阅读原文查看。

用Java创建一个RESTful Web服务不难。事实上，像Spring Boot、Eclipse MicroProfile和Jakarta EE这些工具使得RESTful Java应用程序的开发相对容易。

但是许多RESTful We服务的问题并不在于开发而在于设计。本文将解决这些Web服务的设计问题，并揭示软件开发者在创建RESTful API时所犯的常见错误。

RESTful API的关键原则：URL和HTTP方法

在开发RESTful Java API时，设计人员需要考虑两个关键元素：

URL模式
使用哪种HTTP方法

我们强调的第一个重要原则是，资源应该始终通过惟一标识它们的URL访问。

对于任何使用过Web浏览器的用户来说，这是一个全新的理念。当我们访问网页或下载基于Web的PDF文件时，我们将浏览器指向标识该资源的URL。同样的概念也适用于使用RESTful Java Web服务访问服务器端资源的时候。如果jQuery或Angular客户端需要操作资源，则应该有一个唯一的URL，该URL使得相关的JavaScript代码可以标识定位对应的RESTful资源。

有意义的、唯一的RESTful URL示例

我经常使用一个“剪刀-石头-布”的小应用来对一些软件开发理念进行原型验证。在这个应用中，我会写一个组件来跟踪输（losses）赢（wins）和平局（ties）的得分结果。

RESTful API教程：学习关键的Web服务设计原则

一个有效的RESTful API允许用户与得分（score）进行交互，它的设计将包括以下URL：

www.mcnz.com/rps/score

当用户通过浏览器、通过RESTful JavaScript应用程序或通过Spring Boot MVC组件访问此URL时，他们将得到当前score的描述。RESTful Java API应该以JSON格式返回以下结果：

{ "wins":"5", "losses":"3", "ties": "0"}

如果RESTful JavaScript客户端只对wins感兴趣，URL应该遵循可预测的格式，其中wins是score的子资源：

www.mcnz.com/rps/score/wins → returns { "wins":"5"}

事实上，返回JSON格式的wins可能有点过头了。只要将wins的数目以文本格式返回即可，所有客户端都可以轻松地使用该结果，而不管它们是否可以解析JSON。因此，最好采取以下措施：

www.mcnz.com/rps/score/wins → returns "5"

looses和ties应该遵循类似的RESTful URL格式：

www.mcnz.com/rps/score/losses → returns "3"

www.mcnz.com/rps/score/ties → returns "0"

正确的RESTful HTTP方法示例

到目前为止，所有RESTful API示例都设定为简单的GET调用。事实上，对于通过URL与RESTful资源交互来说，HTTP协议提供了许多不同的方法。当接收到一个URL调用时，服务器通常假定它是GET请求。但是，RESTful API设计者至少应该考虑另外三种HTTP方法，即POST、PUT和DELETE。

RESTful设计规则：GET调用不能改变服务器状态

要处理HTTP方法，需要遵循重要的RESTful设计规则。RESTful Java API设计者如果违反了这些规则，就会误入歧途。

首要原则是，GET调用永远不能改变服务器上任何RESTful资源的状态。上述的RESTful API完全符合该规则。

RESTful PUT和DELETE方法需要遵守幂等原则

虽然并不是一个严格的规则，但PUT和DELETE方法大致映射了保存和删除的概念。如果设计人员想要从服务器中删除资源，他们应该使用HTTP DELETE方法。如果需要创建新资源或需要更新现有资源，则应使用PUT方法。

PUT和DELETE方法对于保存和删除数据来说是相对简单的。但这也是RESTful Java API设计人员经常遇到麻烦的另一个陷阱。这就引出了第二条规则：HTTP方法要具备幂等性。

如果某件事是幂等的，意味着它可以重复进行，但结果总是一样的。

例如，假设客户端发出RESTful DELETE请求删除编号为271的记录。这个调用可进行一次，也可能进行100次。无论如何，最终的结果必须是一样的，即编号271的寿终正寝。下面的场景就是幂等的。

HTTP DELETE || www.mcnz.com/rps/score?record=271 #Good RESTful Java design

反例是，删除数据库中最老的10条记录的请求。

HTTP DELETE || www.mcnz.com/rps/score?oldRecordsToDelete=10 #Bad RESTful Java design

在反例中，RESTful URL将使数据库在每次新调用时处于不同的状态,直至删除数据库中的每条记录。这个方法不是幂等的，因此违反了基本的RESTful API原则。

PUT方法也必须是幂等的。因此，如果需要将wins的数量从数据库中的当前值更改为10，那么一个好的RESTful Java API将如下所示：

HTTP PUT || www.mcnz.com/rps/score/wins?value=10

我们可以一次又一次地调用此方法，每次调用之后，服务器将处于相同的状态：wins的得分是10。这个RESTful Java API是幂等的。反例是，每次调用该方法时添加10次win：

HTTP PUT || www.mcnz.com/rps/score/wins?add=10

这个方法不是幂等的，因为每次调用时，wins的数目会跳转到一个新的值。wins的得分开始时是10，第二次调用时20次，下一次30次。使用此方法，资源的最终状态是不可预测的。它不是幂等的，也不是好的RESTful API设计。

从技术上讲，URL末尾的查询参数应该仅用于查询。在本例中，我们使用查询参数向服务器传递有效负载。这样做使示例更简单，但也突破了查询参数本来的用途。在未来的RESTful API设计教程中，我们将演示如何在PUT调用期间将JSON字符串作为有效负载的一部分来进行传递，这是比使用查询参数更好的设计。

保守的使用RESTful API设计的瑞士军刀：POST方法

我们已经知道，从数据库中删除10条最老的记录是对DELETE方法的错误使用，而简单的数字增量则是PUT方法的糟糕应用，这是否意味着我们不能用RESTful API来完成这些事情？当然不是。

目前为止，我们建立了两个非常重要的规则：

GET调用不能更改资源的状态。
PUT和DELETE方法必须是幂等的。

但是请注意，我们还没有提到POST方法。在上述规则之外的任何场景中，都可以使用POST方法。因此，如果要从数据库中删除10条最老的记录，可以使用POST方法。如果想将wins得分加10，同样可以使用POST方法。POST方法，从某种意义上讲，是RESTful设计的瑞士军刀。

HTTP POST || www.mcnz.com/rps/score/wins?add=10

HTTP POST || www.mcnz.com/rps/score?oldRecordsToDelete=10

当然，如果将POST方法作为一种普适的方法，来应对RESTful API设计的所有挑战，还是存在风险的。仅仅因为没有违反关于幂等性的规则或滥用GET、PUT和DELETE方法，并不意味着已经正确地设计了RESTful API。过度使用POST方法本身也是RESTful设计的误区之一。

通常，我们会看到一个被认为是RESTful的系统中，设计人员投机取巧地将API的所有排列都设计为POST调用。仅仅因为没有违反重要的RESTful原则，并不意味着已经开发了一个有效的RESTful API。当RESTful API设计者对他们的问题域采取“基于服务”的方法时，经常会出现频繁使用POST方法的趋势。创建RESTful API时，始终在系统中应用“基于资源”的方式十分重要。

白小白****：

此处实际上稍微令人费解，原因在于基于服务和基于资源的概念在本文中并未明确的给出解释。其实可以将此区别理解为传统的SOAP与REST的区别之一，这里有一篇文章我觉得写的很好（ https://blog.csdn.net/caisini\_vc/article/details/48465731 ）。比如，一个删除用户的操作，在基于服务的模式下，所有的 SOAP 消息经过代理服务器，只能看到（http://localhost:8182/v1/soap/servlet/messagerouter, HTTP POST）这样的信息，如果代理服务器想知道当前的 HTTP 请求具体做的是什么，必须对 SOAP 的消息体解码。而在基于资源的模式下，URL的描述是（http://localhost:8182/v1/users/{username}，DELETE），这不仅有利于服务器的识别，更可以实现安全控制。

还有很多需要学习的东西，比如将有效负载数据传递给服务器的最佳实践，如何构造URL以识别资源，以及如何避免在“基于资源的设计”中应用了“基于服务的方法”这样的误区。我们将在随后的RESTful API教程中介绍这些内容。但是，构建URL和正确使用HTTP方法是每一个优雅的“基于资源的API”设计的坚实基础。

RESTful API教程：学习关键的Web服务设计原则 关于作者：Cameron McKenzie from TechTarget, TheServerSide.作为JavaEE软件工程师，Cameron McKenzie已经有20年的从业经验。他目前的专注于敏捷开发、DevOps和基于容器的技术，如Docker、Swing和Kubernetes。