微服务架构模式是一种将单个应用程序开发为一套小型服务的方法，每个服务都在自己的进程中运行，并通过轻量级机制进行通信，通常是 HTTP 资源 API。这些服务围绕业务功能构建，并且可以通过全自动部署机制独立部署。这些服务的集中管理极少，可以使用不同的编程语言编写，并使用不同的数据存储技术。虽然它们的优势使它们在过去几年中非常流行，但它们也带来了增加分布、削弱一致性和需要成熟的运营管理的成本。

大多数内部 REST API 都是为单个集成点构建的一次性 API。在本文中，我将讨论非公共 API 的限制和灵活性，以及在跨多个团队进行大规模 RESTful 集成中吸取的教训。

一种（由 Leonard Richardson 开发的）模型，将 REST 方法的主要元素分解为三个步骤。它们引入了资源、HTTP 动词和超媒体控件。

我的同事吉姆·韦伯以其在企业集成中采用轻量级和面向业务的方法而闻名。他还以其健谈和有趣的演讲风格而闻名。因此，我很紧张，也很兴奋能与他一起在 2008 年 QCon 大会上发表主题演讲。他做了一个非常有趣的演讲，其中穿插了一些严肃的内容。然后我们就直接开始了——可能是演讲前的啤酒起了作用。我们谈论了企业集成的历史、那些自以为强大但实际上只是臃肿的系统的增长、敏捷思维的作用、网络的影响（包括吉姆关于网络发明原因的独特理论），以及这如何导致游击队 SOA。

本文讨论了服务提供者和消费者社区发展过程中的一些挑战。它描述了当服务提供者更改其契约的某些部分（尤其是文档模式）时出现的一些耦合问题，并确定了两种广为人知的策略——添加模式扩展点和对接收到的消息执行“恰到好处”的验证——来缓解此类问题。这两种策略都有助于保护消费者免受提供者契约更改的影响，但它们都没有让提供者了解其使用方式以及在演进过程中必须维护的义务。本文借鉴了其中一种缓解策略（“恰到好处”的验证策略）的基于断言的语言，描述了“消费者驱动的契约”模式，该模式使提供者能够洞察其消费者的义务，并将服务演进集中在交付消费者所需的关键业务功能上。