New best friends: APIs and Integration

In some companies, APIs already have a firm place in the integration team’s toolkit. However, there are also companies who never seem to have heard of an API. That’s ok, for as long as there aren’t any activities which require an API.

The need to use APIs could for instance come from:

Forearmed is forewarned

As some of the mentioned points above could become reality at short notice, it’s worth starting preparation now, which could involve the following topics:

The further you go with these steps, the faster and easier it is to implement your API needs when they occur.

Ideally, these preparations should be carried out to such an extent that you can justify  potential API requests, rather push usage of APIs proactively.

Solutions

There are various solutions on the market, which can roughly be differentiated as follows:

Pure API solutions do not offer classic integration technologies or provide them only via extensions, while an “all-in-one” solution combines all technologies on one platform and allows seamless interaction.

And this is the biggest challenge for many companies. Frequently, not all components involved (e.g. applications) are already API-compatible. Some will never be made API-compatible, whether due to prohibitive cost or technical feasibility.

An integration solution that can only serve APIs would be extremely limiting, indeed, useless for certain tasks. A pure API solution would essentially be a further standalone system.

An integration solution that combines API activities with integration tasks would give you unlimited functionality. Essentially, the API could be seen as a type of envelope, which you fill with whatever you want.

Some examples:

Pitfalls

The interaction of an API with non-API-compatible components provides many options. At the same time some topics need to be considered:

• Availability of non-API-compatible components
  If a service (e.g. a website or smartphone app) needs to be available around the clock, then its underlying components also need to be available 24/7. If this can’t be assured, then there should be a proper error message (e.g. ‟Dear user, our service is currently unavailable due to maintenance”, is much better than a technical message such as “500 – internal server error”).
• Performance of non-API-compatible components
  Any activity carried out within an API takes time. This time increases the response time for any request made to an API. If there is an expectation that an API’s response time is under 100 milliseconds, yet the response time of the system in the background that feeds the API with its information is 2 seconds, then that expectation simply can’t be met. You also need to check whether multiple, parallel calls slow down the response time even further.

Conclusion

So far, there hasn’t been a huge wave of moving away from classic integration or EDI to API. That’s probably because many of the interfaces in use are well-established and change is always associated with cost and risk.

Nevertheless, there is a clear trend in all areas of creating value by integrating and using APIs, whether this is for their ability to process in real time or for the advantages of an abstract, uniform interface layer.

A clear recommendation for APIs is therefore to “act” rather than “react”. Then you’ll already be prepared for the issues each IT department will need to consider sooner or later.