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

23天前

简单原则更利于掌握和实践:有意义的、唯一的URL,GET不进行写操作,PUT和DELETE要具备幂等性以及审慎的使用POST。

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

摘要:

简单原则更利于掌握和实践:有意义的、唯一的URL,GET不进行写操作,PUT和DELETE要具备幂等性以及审慎的使用POST。

作者:Cameron McKenzie

译者:白小白 

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

原文:https://www.theserverside.com/video/A-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允许用户与得分(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”设计的坚实基础。


关于作者:Cameron McKenzie from TechTarget, TheServerSide.作为JavaEE软件工程师,Cameron McKenzie已经有20年的从业经验。他目前的专注于敏捷开发、DevOps和基于容器的技术,如Docker、Swing和Kubernetes。





关于EAWorld:微服务,DevOps,数据治理,移动架构原创技术分享,长按二维码关注



COMMENTS

需要 后方可回复
如果没有账号可以 一个帐号。