如何定义 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 控制器类，如下所示：

@RestController

public 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

微服务应该松散耦合 = 最小依赖。微服务是一种架构风格，它将应用程序构建为服务的集合，这些服务是高度可维护和可测试松耦合可独立部署围绕业务能力进行组织。https://microservices.io/可以使用 WADL 定义合约在客户端和服务器之间使用契约意味着在实现客户端时更少的错误，更少的误解。这就是合同的好处。