If you’ve been building websites sites for a while you will realise that no site lives in isolation. Almost every site you build integrates with some form of API, and this is especially the case for the more enterprise sites where data is often synchronised back to a CRM system or similar. Drupal’s hook and service architecture means that you can easily build integration points to that API to pull in data.
Pulling in data from an API into a Drupal site means installing an off the shelf module or creating a custom module to provide the integration. What route you go for depends on the integration, but for enterprise sites the API is quite often very custom to the business. I have even seen APIs being built at the same time as the site that it needs to integrate with, which is especially the case for startups and new businesses.
One of the biggest issues in getting things working with a site that relies heavily on an API is testing. Both in terms of behavioural testing and user testing you need to be able to have a repeatable set of items that you can use and having an active changing API makes this a little bit tricky. If your API is still being built then you literally have no API to integrate against and so you can’t build your site yet.
This is where stubbing comes in. Instead of directly asking the API for data we can swap out the API integration for a different data source. In other words we redirect the API calls to a local file or database table so that the functionality still exists but the data source is different. This is possible to do in Drupal thanks to the modular and extensible way in which services are used.
