RESTful API教程：学习关键的Web服务设计原则
用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”设计的坚实基础。
原文发布时间为：2018-09-5
本文作者：Cameron McKenzie
