Imagine that a user has plugged into your API and triggers a request, only to be met with an error message. Now imagine all of this is happening while they’re traveling at 70mph on the highway. For Henrik Segesten, cloud domain architect at Volvo, making sure that this sort of thing doesn’t happen isn’t the stuff of bad dreams — it’s part of his day to day routine.

Segesten and co. can’t afford to make the same mistakes that API developers working on a plugin for, say the Nest thermostat can. Rather than cause a minor inconvenience for the user, the potential impact of flaws in an automobile scenario could be life-threatening. From the transmission to the software powering onboard electronics, automotive grade equates to rigorous testing and extremely high reliability standards.

But this is about more than just ensuring that automobile APIs are robust and bug-free – after all, that should be the aim of any API developer. Rather, it’s about improving longevity (something we’re writing extensively about currently) and compatibility.

Right away, we can see that there’s something of a disconnect here: it’s extremely difficult, if it’s even possible at all, to ensure that every step in the API process can be monitored with the sort of obsessive quality control demanded by true automotive grade standards. Imagine, for example, telling API consumers that they’re only allowed to use your APIs if they do all of their coding on a MacBook Pro, produced no later than 2015, running OS X 10.10.5 or above.

But, as we’ll see below, there are a number of useful concepts relating to automotive grade that can make a lot of sense in the context of how we design and update APIs as well.

Test It Like it Has to be Automotive Grade

We’ve previously written about the importance of testing, both your APIs themselves and your documentation, yet it’s something that some API developers continue to overlook.

Think about some of the processes that a car, and its component parts, need to go through before the latest model rolls off the production line:

• Testing for extreme temperatures
• Analysis of how the vehicle performs on different terrains
• Adequate warning when something isn’t working properly
• Lots of redundancy built in

There’s an important lesson from automotive grade in there for API developers: it’s highly likely that the tests outlined above are far more thorough than anything you put your APIs through…unless you work at Volvo with Segesten, where they’re trying to establish API architecture that can remain solid for decades.

While “bank grade” and “military grade” are often used in relation to security and construction materials respectively, automotive grade is a term that’s a little more tightly defined.

Segesten outlines automotive grade as being a hardware concept with “a measure on the quality level of all parts in a car…with an expected lifespan for each and every component, down to every nut and bolt, that is equal to or greater than the expected lifespan of the car.” That usually equates to around 30 or 40 years.

In the context of software development, we need to loosen up that definition a little bit. We aren’t necessarily trying to create an API that will last for that period of time so much as, as Segesten jokes, giving some thought to “the poor girls and guys who need to re-implement your API in twenty years’ time.” He highlights the fact that “automotive grade translates to longevity, so you need to design with longevity in mind.” In other words, just because something seems to work for now doesn’t mean that it’s the right choice.

Automotive Grade and Futureproofing

Segesten advises looking backwards in order to plan for the future to consider what the main drivers have been in web-oriented software and API development throughout the past 30 years. It’s worth reproducing that list here:

But this doesn’t mean that all API developers should be shunning RESTful development in favor of standards that have been around for 30+ years. Rather, it’s an argument to ensure that your API uses technology that can stand the test of time. In their lifespan, typical APIs will need to be “re-implemented several times along the way … because the old system has died for some reason. Pick your technology wisely.”

Now, let’s think about the protocols/languages etc. commonly used in the API space in 2017:

• JSON
• REST
• SOAP
• XML
• JavaScript
• Open API/Swagger
• GraphQL

It’s interesting to note that, of the above standards listed by Segesten, only JSON, SOAP and XML appear across multiple decades. This doesn’t mean that you should only consider using these data formats when building an API. Rather, it’s evidence that ten years isn’t a long time in the world of software development; developers can ill afford to use the latest, hippest languages and standards unless they’re pretty confident that they have what it takes to stand the test of time. Based on what we’ve seen so far, REST appears to fit that bill.

But it’s worth remembering, as Segesten says, that there’s more to an API than just the technology you use; the best APIs can thrive regardless of the technology that power them.

Automotive Grade and Backwards Compatibility

As important as it is to futureproof an API, it’s just as important to ensure that it’s backwards compatible too. For example, what would happen if a car buyer disables all the connectivity features in a car, uses it for ten years, then sells it? When the next buyer turns on a connectivity feature, the car will be consuming the associated APIs for the first time.

The lesson here is that old versions of APIs never die, and you’ll inevitably need to maintain them because:

• You can’t be sure that all users will migrate to later offerings
• Certain products/hardware may not be capable of communicating with your newest API
• You need to remain compatible with hardware that will go offline, i.e. asynchronous communications.

Designing APIs with backwards and forwards compatibility in mind from the start – using extensibility, optionality, and so on – is much easier than trying to simultaneously manage tens of different versions … as the folks trying to support users with versions of Windows that are decades old will probably tell you. In fact, there is a strong case that versioning shouldn’t even happen at all with web APIs.

Lastly, Segesten reminds us that it’s a good idea to keep things as simple as possible. “If you have to have complexity…try to put all of that complexity on the server side, because you can update that all the time but the API should never have to be updated.” When that hypothetical ten year old car we mentioned above finally hooks up to a Volvo API, it should be more or less good to go if you make most of your changes server-side.

Final Thoughts

As we’ve seen above, particularly given the lack of control API developers have over how and where their products are used, actually producing an automotive grade API is extremely difficult. If we take the term at face value, i.e. remaining valid for 30 or 40 years, it may not be possible at all.

Any experienced API developer knows that there are too many variables to control to guarantee that a service will still be working in 2047. With that in mind, it might be better to consider employing the principles of “automotive grade”, such as:

• Using futureproof, or at least as futureproof as possible, languages and methodologies
• Have compatibility strategies in place – how do you version handle your APIs?
• Keep things simple, both in terms of functions and documentation, and testing as thoroughly as possible to make sure it all works as expected

The good news is that, for the majority of us, our API consumers will never be using our products or services at 70mph. But that doesn’t mean that it’s not a good idea to prepare like they might be…