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