WebAPI Tip #4: Does This Framework Do SOA?

This post is a commentary on the statement: "We are sticking with WCF because we want a service oriented architecture."

SOA is a three letter acronym that created a fervor from the server closet to the executive boardroom.  A decade of labor by standards committees, tool vendors, framework builders, consultants, and hucksters made sure SOA became the silver bullet for enterprise architecture.

If I look through the noise for the pragmatic essence of SOA, I see three noble goals:

- Software encapsulation – or the ability to hide complexity behind coarse grained interfaces.

- Software autonomy - or the absolute control of the execution environment and the resources required by software, as well as the freedom to make independent decisions about implementation details.

- Software interoperability – or optimizing for reuse by relying on standard application level communication protocols.

Those three goals are entirely possible with HTTP based services and the ASP.NET WebAPI. The S in SOA doesn't stand for SOAP.

I know many people will say the additional metadata commonly associated with SOA (like WS-Metadata Exchange, WS-Policy, and XML Schema, to name just a few) is also a core part of SOA. I'd argue the metadata was good for vendors who built software to manage the complexity of the metadata.

KISS it goodbye with the WebAPI.