如何定义 REST 服务契约以在多个类似服务之间共享使用？

Question

我正在用 Java 实现一系列 REST 微服务——我们称它们为“适配器”。每个服务都从特定的源类型读取数据，并以相同的方式提供结果。主要思想是为所有这些提供相同的接口（服务合同），以获得可互换性。我想避免代码重复并重用服务的服务合同。看来我正在重新发明轮子。对此有标准方法吗？我尝试以 Java 接口的形式为 Spring MVC Controller 类和随附的 DAO 类提取服务合同CustomObject：public interface AdapterController {    @RequestMapping(method = RequestMethod.GET, value = "/objects/{name}")    CustomObject getObject(@PathVariable final String name);}然后将它们放入单独的 Maven 项目中，将其设置为原始项目中的依赖项，并重写 REST 控制器类，如下所示：@RestControllerpublic class DdAdapterController implements AdapterController {    @Override    public CustomObject getObject(String name) {        return model.getByName(name);    }我也可以在客户端代码中重用 DAO 对象，但是接口类在客户端是无用的。1）总结：可以在不同的服务实现之间重用/共享服务契约吗？这样做的代价是什么？是否有共享服务合同的最佳实践？2）下一个问题是关于服务合同和消费客户。可以在服务和客户端之间共享合同吗？Java/方法中有一些工具吗？

Answer 1

这违背了微服务的心态，从长远来看，共享代码是一个坏主意。

如果您开始共享代码，您将慢慢构建一个分布式单体，其中多个服务相互依赖。

之前很多人都讨论过这个问题：

微服务-不创建-共享库

服务间过度耦合的弊端远比代码重复带来的问题严重

微服务：共享库 vs 代码重复

构建微服务的关键是：

• 一项服务应该非常擅长一件事

• 保持小

• 有一个非常有据可查的 api

• 当您需要删除一个微服务时，应该这样做，因为很少需要更新其他服务

• 避免代码共享，将所有库视为 3rd 方库，甚至是您自己的库

Answer 2

1. 微服务应该松散耦合 = 最小依赖。

   微服务是一种架构风格，它将应用程序构建为服务的集合，这些服务是

• 高度可维护和可测试

• 松耦合

• 可独立部署

• 围绕业务能力进行组织。

https://microservices.io/

可以使用 WADL 定义合约

1. 在客户端和服务器之间使用契约意味着在实现客户端时更少的错误，更少的误解。这就是合同的好处。