マイクロサービスアーキテクチャパターンは、単一のアプリケーションを、それぞれが独自のプロセスで実行され、多くの場合HTTPリソースAPIである軽量なメカニズムで通信する、小さなサービスのスイートとして開発するアプローチです。これらのサービスは、ビジネス機能を中心に構築され、完全に自動化されたデプロイメント機構によって独立してデプロイ可能です。これらのサービスの集中管理は最小限であり、異なるプログラミング言語で記述され、異なるデータストレージ技術を使用する可能性があります。その利点からここ数年非常に流行していますが、分散の増加、一貫性の低下というコストがかかり、運用管理の成熟度が必要です。

ほとんどの内部REST APIは、単一の統合ポイントのために目的が構築されたワンオフAPIです。この記事では、非公開APIで持つ制約と柔軟性、および複数のチームにわたる大規模なRESTful統合の教訓について説明します。

RESTアプローチの主要な要素を3つのステップに分解したモデル（レオナード・リチャードソンによって開発）。これらは、リソース、HTTP動詞、ハイパーメディアコントロールを導入します。

私の同僚であるジム・ウェバーは、エンタープライズにおける統合に対する軽量でビジネス指向のアプローチで高い評価を得ています。彼はまた、非常に堅牢で面白いスピーカーとしても評判があります。そのため、QCon 2008での基調講演で彼とステージを共有することに興奮すると同時に緊張しました。彼は、いくつかの重要な情報が織り込まれた、とても面白いプレゼンテーションをまとめました。その後、私たちは飛び込みました。おそらく、講演前のパイントのおかげでしょう。エンタープライズ統合の歴史、強力だと思っているが実際にはただ太っているだけのシステムの成長、アジャイル思考の役割、Webの影響（ジムがWebが発明された理由について独自の理論を述べています）、そしてこれがどのようにゲリラSOAにつながるかについて話します。

この記事では、サービスプロバイダーとコンシューマーのコミュニティを進化させる上での課題について説明します。サービスプロバイダーが契約、特にドキュメントスキーマの一部を変更するときに発生する結合の問題をいくつか説明し、そのような問題を軽減するための2つのよく理解されている戦略（スキーマ拡張ポイントの追加と、受信したメッセージの「十分な」検証の実行）を特定します。どちらの戦略も、プロバイダー契約の変更からコンシューマーを保護するのに役立ちますが、どちらの戦略も、プロバイダーがどのように使用されているか、および進化するにつれて維持する必要がある義務についての洞察を提供しません。これらの軽減戦略の1つである「十分な」検証戦略のアサーションベースの言語を利用して、この記事では、コンシューマーへの義務についての洞察をプロバイダーに与え、コンシューマーが要求する主要なビジネス機能の提供を中心にサービスの進化を焦点を当てた「コンシューマ駆動契約」パターンについて説明します。