If you’ve ever tried to integrate software, you’re painfully aware that the reason integration is such a challenge is because this piece of software doesn’t want to talk to that piece of software. For whatever reason, the APIs or the message data formats aren’t compatible. So we roll up our sleeves and build a custom integration.
Such custom integrations are the bane of any legacy distributed environment. They’re inflexible and difficult to maintain. Sometimes, it’s a challenge simply to understand what the coder was thinking when they built the damn thing. It seems that every such integration is unique and different from every other such integration, as though they were individual snowflakes. No two alike.
Contracted interfaces, in particular Web services, were supposed to address this snowflake problem. Everybody agreed on a WSDL file, and now we have a uniformity of interface that will give us loosely coupled plug and play. A great story to be sure, and WSDL indubitably moved the ball forward, but we still had custom operations and schemas that described the message formats. And it seemed that every schema was unique to a particular situation. In other words, the snowflake problem again.
Now we have RESTful endpoints. No more custom operations. All you get (assuming HTTP is your transport) are GET, POST, PUT, and DELETE. We also have standard Internet Media Types (formerly called MIME types). As long as our representations (message formats) comply with a standard Media Type, we’ve solved the snowflake problem once and for all.
Except, of course, standard Internet Media Types work well for browser-based interactions, but don’t cover all the arbitrary integration scenarios we’d like to implement. So we resort to custom Media Types. In other words, RESTful snowflakes.
The reason we haven’t seemed to make much progress solving the snowflake problem is because the solution doesn’t depend on some newfangled architectural style. Rather, we must change our perspective on custom integration entirely. Fundamentally, whatever integration you’re trying to implement today isn’t new. Somebody else has probably run into the same problem before. After all, there are only so many ways that two pieces of software might want to communicate, especially in the enterprise context.
You might think that your bank, or manufacturer, or government agency is doing what it’s doing in some unique way that requires snowflake integrations. Don’t flatter yourself: integrations aren’t where your company is going to achieve its strategic differentiation. To solve the snowflake problem, bite the bullet and find someone else who’s created an API and/or message format that meets your needs, and use that. If you find that you truly have a unique situation, then publish your integration metadata so the next poor slob who comes along with the same problem can reuse your work. Over time, we’ll have a global library of integration metadata so robust that the snowflake problem will finally be a thing of the past.
