The microservice architectural pattern is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies. While their advantages have made them very fashionable in the last few years, they come with the costs of increasing distribution, weakened consistency and require maturity in operational management.

Most internal REST APIs are one-off APIs purpose built for a single integration point. In this article, I'll discuss the constraints and flexibility that you have with nonpublic APIs, and lessons learned from doing large scale RESTful integration across multiple teams.

A model (developed by Leonard Richardson) that breaks down the principal elements of a REST approach into three steps. These introduce resources, http verbs, and hypermedia controls.

My colleague Jim Webber has built quite a reputation for taking a lightweight and business-oriented approach to integration in the enterprise. He also has a reputation for being a very robust and entertaining speaker. So I was as nervous as I was excited to share the stage with him for a keynote at QCon 2008. He put together a wonderfully funny presentation with some serious tidbits of meat woven through it. We then just dove in and did it - possibly helped by the pre-talk pint. We talk about the history of Enterprise Integration, the growth of systems that think they are strong but are really just fat, the role of agile thinking, the influence of the web (including Jim's unique theory on why it was invented), and how this leads to Guerilla SOA.

This article discusses some of the challenges in evolving a community of service providers and consumers. It describes some of the coupling issues that arise when service providers change parts of their contract, particularly document schemas, and identifies two well-understood strategies - adding schema extension points and performing “just enough” validation of received messages - for mitigating such issues. Both strategies help protect consumers from changes to a provider contract, but neither of them gives the provider any insight into the ways it is being used and the obligations it must maintain as it evolves. Drawing on the assertion-based language of one of these mitigation strategies - the “just enough” validation strategy - the article then describes the “Consumer-Driven Contract” pattern, which imbues providers with insight into their consumer obligations, and focuses service evolution around the delivery of the key business functionality demanded by consumers.