APIs have become the new middleware, enabling front-end apps to connect with back-end systems, connected objects, and sensors to talk to cloud services, applications to interoperate, and more. Initially used internally, APIs have taken on a life of their own and are increasingly used as a means to communicate with clients or partners, either to support an existing business process or to become a business of their own.
Your business is increasingly relying on APIs. Yet, unlike most mission critical business applications, the delivery of APIs is rarely industrialized the way modern software delivery is. That is wrong, and here is why.
APIs are a behind the scenes story
Unlike a shiny website or a cool mobile app, APIs are invisible to the eye of the user -- except when things go really wrong.
Detecting bogus responses or confirming the proper handling of error conditions cannot always be performed through UI testing. It may be that the range of parameter input from the application will not trigger certain use cases. Or that error conditions returned by the API are not surfaced through the application, showing instead a frustrating "please wait" message while retries ensue.
As in every software stack, each layer must be tested independently from the layer above and the layer below. Since an API does not have a UI, it must be tested through calls, the same way the application will do.
It's not even that hard: use the API contract
REST APIs implement standardized architecture principles and concepts, which make their behavior predictable. At the core of every API resides a contract (the most popular API contract languages are Swagger, RAML, and API Blueprint) that describes all the methods that can be called along with the parameters that can be passed, and the expected output.
Making calls to the API can be done very easily since the API URI is "human readable," and so are the payload formats (JSON, XML for example). Granted, they are not necessarily the most fun commands to type, but to me typing lastname="smith"&firstname="john" beats binary encoding any day.
There are also tools that make this a lot easier than typing all these calls by hand. Some run on the command line, like cURL, while some offer a more sophisticated user interface for configuring and stringing the calls, like Runscope or DHC by Restlet. (Disclaimer: I work for Restlet)
Make it part of your software delivery toolchain
Testing an API should not be limited to making a few calls and checking that the returned values are the expected ones. Quality automation applies to APIs the same way it applies to the rest of the software stack.
Therefore, calls to APIs should be assembled into proper test scenarios that are executed every time a new version is built or delivered. Consider adding your API tests to your continuous integration and delivery software toolchain (built with Jenkins or Bamboo for example): most of the tools mentioned above support this capability, with varying degrees of automation.