New technologies are emerging every day and people tend to focus entirely on the novelty disregarding ones that keep the world spinning.
The five myths about API management and SOA are extracted from IBM whitepaper “API management is the SOA renaissance”. You can read the original document here.
When innovation is required, you are often tempted to start with a blank piece of paper yet this time you cannot afford to do so. While it is true that business models are fundamentally changing, implementation continues to require robust integration of people, processes and software, only now at a much grander scale and an even higher speed. SOA and API Management are inextricably linked and neither is whole without the other. API management delivers the business centricity and business model that many SOA initiatives have historically lacked. SOA delivers the experience and engineering discipline that drives more effective API design and provides robust integration to systems of record. All APIs are services but not all APIs are well-designed services.
Consider below some important examples of the myths about SOA and API management.
At a technical level, more similarities than differences exist between API management and SOA. In fact, at the foundation of an effective API is a well-designed service. Some of the most important parts of an API are its interface, the business task that it represents and the associated business contract, which are all key elements of a service definition.
It is true that most modern APIs are based on REST/JSON rather than SOAP. However, the use of REST/JSON rather than SOAP does not mean that there is no use for the formalism of SOAP; merely that such formalism is not necessary for human-based consumption of APIs and services. In machine-to- machine communication or when using formalized composition tools, SOAP still has plenty of uses. Choose the right binding for the purpose; there are good reasons why the industry has invented more than one option.
While there is some truth to this statement, in its totality it is a myth as well. APIs have product nature and therefore, APIs must be managed as products. SOA governance is less concerned with productization of assets than it is concerned with determining and governing the process of creating an effective portfolio of reusable assets in the first place. In that fashion, API management and classical SOA governance are highly synergistic.
Lack of governance might allow you to create API products faster but it also makes you lose control a lot faster :-) . APIs that make up your company’s external persona are an important part of your product portfolio and must be managed as such with clear ownership and responsibilities. That said, governance should be lighter for an API than for the typical lifecycle of a back-end software service.
That is like saying that the sun does not shine. Obviously, disruptive changes do happen and when they do, you must handle them appropriately. Claiming that you do not need versioning merely means that you are making consumers of an API figure out the versioning themselves. With that said, because APIs in many ways are business products, you should reduce version churn by only defining and publishing a new official version when an update is not backwards compatible. Versioning is still needed but you must version wisely.
To learn more about the SOA and API management please contact us, or visit the following website: ibm.com/soa