How To Choose An Integration Protocol — Aspiration and Advisory

Every developer faces a situation when he has to set up an integration between two applications and has to select an integration protocol. There are multiple options — use one of the standard protocols, exchange files, or even create a new protocol from scratch. But which one to choose?

Do Not Reinvent The Wheel

In most cases, the best solution is the simplest one. Currently, you may choose one of several popular implementations. For example, you may use XML or JSON format and implement RESTful service using HTTP to pass that data.

This approach has tons of advantages. These protocols are widely supported so that you can find a library, plugin, or extension for pretty much every application framework and platform. Consequently, it is easy to modify and integrate applications that support these protocols.

There is only one possible drawback. Suppose you are planning to integrate with some old or legacy application older than ten years. In that case, there is a chance that nobody supports it and these protocols are very hard or impossible to implement there.

Good Old Files

Exchanging the data using regular files is an old but very reliable approach that was supported fifty years ago and probably will be supported fifty years later. So, it is a perfect way to pass and share information with legacy systems or systems that has to work without significant changes for tens of years.

You still have to choose some transport layer protocol, though. It is a good idea to support several protocols to raise a chance that at least one will still be maintained in the future. The most obvious choices are HTTP(S), FTP(S), and SSH.

The drawback of this approach is the necessity to write an additional level to support file system manipulation. These may be checking the last change data of the file, monitoring specific directories for new files, and so on.

Bit Of Ingenuity

Some unique or unusual cases may indeed require a brand new custom protocol. Bus these are edge cases, and we are going to check these cases below.

The first case is secure data passing. You do not want to expose not only the content but also the protocol. So, the custom protocol can grant an additional level of protection.

The second and third cases are data passing in high-performance or high-latency systems. They both have similar traits — they need to use a minimum amount of data to get the best performance. So, the custom protocol can help to achieve this goal.

Custom protocols may be text-based or binary. There are just a few cases when a project has custom requirements, so a custom binary protocol is an obvious choice.

All custom protocols have only one drawback — it takes a lot of resources (time, money, human) to implement and support it. So, think twice whether you need it or you can use a more straightforward approach.

Here are three common types of protocols you may face in modern applications. Choose wisely and pick the best option based on your situation, project, and requirements.