简短的故事： 我正在寻找教程或github项目，其中有一个RESTful服务设计“最佳实践”的例子。
长篇故事： 我正在阅读用于设计和实现Web服务的“官方”Spring教程： http://spring.io/guides/tutorials/rest
它有一个小项目的例子。他们正在为这个项目使用“六边形架构”和一堆“事件”类。通过它，我不禁注意到，对于一个示例项目来说，它似乎过于设计。有50多个课程，不包括测试。这真的是这种服务的“最佳实践”范例吗？如果没有，还有其他更好的例子吗？
答案 0 :(得分：31)
我不能指出你的教程，但可以根据使用Spring MVC编写RESTful服务的经验来提及一些事情。
将控制器与业务逻辑分开。对控制器的担忧：最重要的是错误处理，也可能是授权。 Controller方法最初可能很薄，只需调度到相应的业务逻辑方法。这不是一件坏事，很快你的控制器会随着客户接口的问题而成长。
谈到错误处理，在RESTful服务中很难做到这一点。您肯定需要通过结构化数据很好地告知客户错误。我想这应该是你所有回复的一部分。您需要确定发回哪些错误信息，哪些是您沉默的，只是记录等等。
最有可能的是，您将获得一些数据对象以及您要发送的响应。将它们装在一个单独的罐子里。添加到此jar接口，由控制器实现。还添加了这些接口的简单第二种实现，可以调用您的服务。在这里，你有一个客户端库。分发它，让您的Java客户满意。
即使现在你有一个很好的Java客户端库，也不要忘记用curl测试你的服务，并通过简单的调用记录如何使用它。让非Java用户满意。
＆＃34; unit＆＃34;有各种各样的库。通过模拟或多或少的Web服务器内部来测试控制器。这些非常有用，但不限于此。有一个qa env，你可以完全部署你的服务，并有一个qa应用程序，可以在qa env上向你的服务实例发送真正的完全成熟的请求，并分析他们的回复。
尝试在不同的调用中保持简单和一致。例如，每个响应可以包含相同的＆＃34;错误＆＃34;具有相同字段的部分以结构化的可编程形式提供有关出错的信息。
REST是一个很好的抽象，但有其局限性：在实践中，/ delete.json？id = 3可能对不同的服务产生非常不同的影响。不要指望您的客户能够猜出＆＃34;添加＆＃34;和＆＃34;删除＆＃34;将在您的特定情况下意味着，因为他们可能会猜测与您的预期不同。相反，请在您的文档中提供有关您的服务将在幕后执行的操作的一些信息。我们尚未处于这样一个阶段，即我们能够通过非常精简的界面进行通信，并且不幸地保持对内部的不可知性。