APIs are the delivery mechanism of the future for IT services to open up a new world of functionality to consumers and businesses alike. This extensive and often public usage requires that even more comprehensive testing of those APIs is critical before release. There are a myriad of technologies and resources out there to drive and test APIs externally, however, there are few resources available which assist with the automation of resources upon which those APIs depend to function. This series will focus on strategies on how to deal with the resources on which APIs depend.
Contrary to popular opinion, Application Programming Interfaces (APIs) are not a new phenomenon but have been in use in well architected computer systems since the dawn of the computing age. From the early days of machine code or assembler programming, it was good practice to isolate functionality and publish an ‘API’ to that functionality so that the functionality could be reused often. These APIs were only available to applications running on the same machine.
As machine to machine communication evolved in the 80s, a new concept called Middleware came into being. Middleware was (and still is) a set different technologies allowed different machines to communicate between each other generally using a messaging paradigm. What is different is that all of these APIs were proprietary, company specific APIs for which proprietary and more than likely internal knowledge was needed to use them.
Arguably the first successful attempt at standardization was called CORBA which was functional but was over complicated and required platform specific SDKs to use. The definition of the SOAP standard was a step forward as the advent of sharing a software contract by way of a Web Service Definition Language (WSDL) meant that the APIs for a given service could be published. As all messages were exchanged via platform neutral XML platform, specific SDKs were no longer needed.
Finally a simpler architecture evolved using REST style functionality with JSON payloads, JSON being less tightly defined and thus simpler to handle that XML which can be extremely complex. Many of the newer API initiatives now use REST with JSON(and often still XML or SOAP), however, these new API initiatives are likely to be dependant on one or more older services developed over the last 20 years particularly in older Enterprises.
The key point here is that many existing services are still in everyday use and are likely to have to be reused as part of any new API initiative as illustrated below:
This diagram is intended to be representative of the selection of existing, reusable services that are likely to be out there for reuse in new API projects. It is not exhaustive and in reality, it is likely that any new API project will have a dependency on one or two such services. However, what all of these type of services will have in common:
- Many of these services will run on large, complex back office infrastructure which is difficult to manage, extremely expensive to replicate and thus is a very scarce resource.
- As such services run on scarce resources, test implementations are likely to be shared across an organization which is incompatible with Agile and CI/CD processes as the state at any one time cannot be guaranteed.
- Many of these services will in turn depend on other services and thus ensuring the availability of a given service has many other complexities.
- When more than one service is required, ensuring consistent test data across these services can be challenging to say the least.
- Often these services may be external and will incur a cost each time they are used thus incurring significant cost the more often they are used.
This presents incredible challenges all the way through the Software Development Life Cycle (SDLC) from the initial prototyping of a set of APIs, to initial and final testing along with ongoing testing of those APIs. Subsequent articles in this series will discuss those challenges along with techniques and methodologies to address those challenges.
