However, they are also prone to the same weaknesses. These include limitations on data size, trade-offs in respect of reliability, and the ever-present risk of response timeouts. While this does not pose an insurmountable problem, care should be taken when implementing solutions to ensure that complex API’s don’t become casualties of the inherent weaknesses in HTTP.

For example, let’s consider a common use-case. ACME Trading’s Widget Application needs to make an API call that fetches data from several different systems and compiles it into a single, tidy response. To accomplish this, our Integration API needs to make fifteen calls across five different systems, transform the responses and then compile the data into a single JSON snippet that conforms to our API’s output specification. Easy!

However, let’s pause to consider. The external API endpoints each have a two second round trip in response time, and each call relies on data returned in a previous call. As such, all calls must be made in tandem. This means that any client consuming our API will have to wait a minimum of thirty seconds for our API to retrieve the data from its various sources. This comes dangerously close to default response timeouts for many clients that are likely to consume our API.

The net result is this; your solution will probably work in Dev & Test environments but when you put it into production, and begin querying external resources that are already under massive load, your two second average response time is likely to rise to three, or even five seconds when the network is running hot (i.e. when your end-users are at their busiest, stressed to breaking-point, and in no mood to deal with technology issues). This is the time that random failures are most likely to appear. Not on your solution but, rather, on all the systems that rely on it.

While your API is happily going about its business, retrieving data, transforming it and serving it in anywhere between 45-75 seconds per request, systems all over the business will be reporting Response Timeout errors from your API because it did not serve its responses in 30 seconds or less.

This is when your phone will start to ring, and the conversations will not be pleasant. Worst of all, there will be nothing you can do at this point to rectify the situation. Your only option is to suggest that server admins across five other systems all restart their services in the hope that this gives back some performance in the short term and gets the business over the current spike in activity. Those support teams won’t thank you for this. Bear in mind that all of their systems are responding in three to five seconds even under massive load; more than acceptable from their point of view. Left unchecked, this will soon become a weekly ritual.

Usually, when this happens, the business blames the underlying technology when the true culprit is poor design and implementation. This situation is actually quite easy to avoid. All it requires is a little forethought and common-sense at the outset. This is the best time to seek advice. You can seek counsel to rectify the situation after the fact but that is, generally, far more expensive both in time and materials as well as damaged reputation to your technical team and, possibly, the business.

The rule is simple. Implemented correctly, API-Led Connectivity is a powerful solution to a wide range of business problems. However, when implemented badly, all it will do is give unwary integration architects and developers enough rope.