We have been working on a few new API offerings at The Workshop this month, which has got me thinking about the shift to communications APIs in general. There is one thing I have not had to think much about – API interoperability.
Historically, interoperability has been one of telecom’s biggest challenges. The telco standards bodies would try to standardize interactions between components. The theory was that as long as vendors followed the specs, everything would interoperate.
The reality is that this never happens.
Technology always grows too complex to standardize everything. Any attempt to apply standards is often useless; vendors extend past the ‘standard’ constantly to differentiate their offerings. This always creates a great opportunity for interop infrastructure like gateways and SBCs to clean up these differences, but it ultimately slows down innovation.
The way the web has worked with interop has been a lot different. In the web world, the way you communicate between systems is with RESTful APIs. RESTful API’s are behind the scenes, secretly running services everywhere. REST works so well because it defines so little – just a URL, a handful of HTTP methods, maybe some HTTP headers, and some body content. Other than the format of the body message, there are no real rules as to what the body should contain. To be fair, there are more complex issues with HTTP that can pop-up like dealing with CORS, but these are general HTTP issues and thus there are abundance of resources to help with these.
In the SIP world, you start out assuming the other system is supposed to interop with yours without adjustment. When it doesn’t then you need to dig into how the other side’s implementation differs from yours and one of you needs to change something to fix that. These kinds of details generally are not publicly available, so that means a conversation with a support tech or engineer who knows the details. Once the issue (or issues, since it is often more than one) is identified, then you need to decide who’s side is going to change. It is that investigation and negotiation that eats up all your time. Small issues turn into large time-sinks.
In the web world there is no out of the box interoperability beyond the HTTP layer. This means you need to read the other side’s documentation and write your code to interact with it accordingly. There generally is no coordination with the other end – you make your code work with the other system and move on. This seems like it might take longer than the interop-by-spec approach, but I find this is rarely the case. In fact, one reason there are so many hackathons producing great new mashups is because it is relatively easy to write to someone else’s API.
At The Workshop we have found working with RESTful API’s to be a relative breeze. We use an API gateway as an added security layer, but this really is not needed for interop. SIP interop, on the other hand, tends to be a lot more time consuming. This is one of many reasons why Communications API’s are becoming so popular. We look forward to continuing the Comms API push with a number of new offerings in this area – stay tuned!