読者です 読者をやめる 読者になる 読者になる

APIインターフェイスの漸進的設計

Martin Fowlerのマイクロサービスの解説の中で、Evolutionary Designというものがあった。関連概念として挙げられていたTolerant ReaderとConsumer-Driven Contractsについてかんたんに調べたメモ。

個人的感想

Tolerant Readerは当然の内容だった。Consumer-Driven ContractsでHTTP APIを公開するのはなかなか難しそうで興味を失った。アイデアは面白い。簡易的なプロトコル、たとえば内部のサービス間通信やDSLなどになら応用可能か。

互換性を永続的に維持するのは困難。最終的には新APIを作り、旧APIを隔離して維持できる仕組みを考えておくべきかもしれない(バージョニング、L7ルータ、Netflix Zuul的なアプリケーションなど)。

これはライブラリレイヤの話にも共通する部分がある。時間を取ってAPI設計について体系的に学ぶべきかもしれない。

APIデザインの極意 Java/NetBeansアーキテクト探究ノート

APIデザインの極意 Java/NetBeansアーキテクト探究ノート

Tolerant Reader

Tolerant Reader

互換性を保つために、クライアント側は必要最低限のフィールドのみを読み、他は無視するようにすること。

Consumer-Driven Contracts

Consumer-Driven Contracts

契約をクライアントごとにマネージするというもの。解説記事を見つけたのであまり調べていない:Consumer-Driven Contracts Design Patternを読み漁ってみた

クライアントはプロバイダに登録し、必要最小限の契約をする。Thought Worksが公開しているPactoというツールは、クライアント・プロバイダの双方が契約を満たすことをサポートするため、スタブ・検証などの機能を提供する。プロトコルはJsonSchemaで定義。

これだけで実戦投入はなかなか厳しそうだが、RAMLやSwaggerのコミュニティで似たようなものがあるのかもしれない。