At first glance, it would seem that the API space has embraced unified design standards. RESTful development uses HTTP to communicate between a client and a server. OpenAPI Spec serves to extend REST APIs, improving documentation and making APIs machine-friendly.

However, with just a little digging, it becomes apparent that this isn’t always the case. Other types of APIs like SOAP and GraphQL remain, and other trends like gRPC, AsyncAPI, etc. are becoming architectural styles in their own right. To put it another way, API standards are still in flux.

What we want to ask today is this: is there any pattern to these styles? Do certain industries use, say, REST more than SOAP (or vice versa)? If we look at different sectors, like healthcare, banking, or eCommerce, do we see significant similarities or dissimilarities in API standards?

We’ll try to answer those questions below, as well as looking at why API development trends and habits remain pretty disparate.

Impact Of Standards In Development

Before we get into APIs, let’s look at web development through a slightly wider lens. Although W3C (the World Wide Web Consortium) establishes web standards that outline how the web works, many of its rules are just guidelines.

Ask a typical developer whether they use Flash or HTML5 to produce animations, applications, or mobile games, and you’ll likely hear them respond with the latter. In fact, it’s not a stretch to say that HTML5 is the standard in that space. Despite HTML5 being released as a W3C Recommendation in 2014, Flash won’t become fully obsolete until 2020 when Adobe plans to “end-of-life Flash.”

Trends like responsive design could similarly be seen as standards for web and mobile development. However, even in 2019, some developers and designers continue to segregate mobile traffic or and use rich design that’s cluttered and ornamental. One notable attempt is eBay’s attempts to prevent users from accessing “classic site” on smartphones.

Wile there are plenty of articles and blog posts about best practices out there to take note of, design and web standards aren’t defined as tightly as you might think that they would be.

API Standards And Different Industries

Of all the “SOAP vs REST vs GraphQL” articles out there, and there are plenty of them, few ever reach a solid conclusion on which is the best. That’s because each format has its own advantages and disadvantages, making it difficult to declare one above all else. You wouldn’t try to write code in C++ for a project that demands the use of Python, and the same is true of APIs.

Banking

In banking and FinTech, security is of the utmost importance. Because RESTful APIs are stateless, each API request can come with authentication credentials rather than relying on cookies or sessions. On the other hand, some folks suggest that SOAP might be beneficial for banking and healthcare organizations because it gives them greater flexibility and control over client/server interactions.

Standards in this space are driven, to an extent, by regulation like 2018’s PSD2 (Revised Payment Service Directive). In this particular example, PSD2 gave API developers plenty of free rein because it allowed developers to enter the financial market by using banks’ open APIs without the need to conform to the compliance and infrastructure requirements traditionally associated with doing so. Future regulatory acts may not be so kind…

Government

Government and healthcare APIs come with all sorts of security data protection hurdles, which can narrow down the available choices to a certain degree. Some comparison articles talk about the importance of legacy support and high-level security offered by SOAP, but this is complicated by the fact that most security and authentication measures like OAuth can be used with both REST and SOAP.

IoT & Streaming

It may not be a sector in the same sense as banking or travel, but it’s worth talking about IoT here because of how it deviates from typical API standards.

Rather than OpenAPI, which there’s more on in the next section, developers working with APIs relating to IoT might use AsyncAPI instead because it’s appropriate for both machine and human interaction.

Asynchronous environments have different standards and different protocols; they’re not using HTTP as much, and most IoT devices are low bandwidth. With security as it relates to IoT being viewed as increasingly important, it’s easy to see a future in which the security sector itself becomes more intertwined with asynchronous APIs.

Transportation & Travel

Historically, plenty of transportation APIs were built using SOAP but many of them – such as Uber, TfL, Lyft, Taxi Fare Finder – are now RESTful. TripAdvisor’s API and most Google APIs relating to travel, such as their Static Maps API and GeoLocation API, use REST too. Yelp currently utilizes GraphQL but, for now, remains the minority.

Social, News & Shopping

GraphQL has definitely been making waves in the API space recently, with major players like Shopify, Major League Soccer, Twitch, Circle and New York Times adopting the framework.

One of the most touted advantages of GraphQL is that it gives users a greater level of control over the data that they request, and receive, from servers. It’s advantageous in situations that you might class as “data-heavy.”

However, as we can see from the shortlist above, there’s not much rhyme or reason beyond that to the organizations that are adopting it: we have sports leagues and review sites sitting alongside payment processors and shopping portals.

It remains to be seen whether or not GraphQL will take hold of the API space to the extent that REST has or remain something of an outlier. Everything from industry norms and target API consumer audience through to security requirements and government regulation affects what an API looks like, and makes it very tricky to tightly define API standards.

• 4 eCommerce Industries That Hinge on API Adoption
• Retail Reborn: The Smart Store Concept

Are Stricter API Standards Necessary (Or Even Possible)?

Within sectors, API developers tend to lean in a similar direction. The shape of existing APIs in the space, particularly those put out by larger developers who have a lot of sway, will undoubtedly have an impact on others in that space. For an example of that, one need look no further than the adoption of GraphQL after Facebook’s role in its creation.

Across different sectors, trying to enforce constrictive standards seems like a pointless exercise – as long as there’s no geographic component involved, a banking API will never need to be able to hook up with a mapping API. In this respect, as we said in our article on API Economy Boosting Principles, there is not (and likely never will be) a silver bullet, or “one size fits all” approach when it comes to building APIs.

That said, in terms of architectural style, it’s worth pointing out that the race isn’t even close right now: even at the end of 2017, REST accounted for more than 80% of APIs on ProgrammableWeb, with GraphQL APIs representing a tiny 0.04%. That balance has almost certainly shifted since then – unfortunately, that’s the most recent data we could find – but probably not by all that much.

Also Read: Builbind With Open Standards Will Result In IT Longevity

De Facto Standards In APIs

Although there may be a lack of consistency around APIs, there are still elements of API development that remain (or should remain) consistent across all types of APIs:

• Documentation
• Versioning
• SDKs
• Developer Experience

Developer Experience This is a burgeoning standard all of it’s own, and it’s still very loosely defined, but it’s something that has a significant impact on API adoption and we think it will continue to become more and more important.

Although methods and implementation may differ there are still best practices in developing APIs that represent standards of a certain kind, i.e. standards are beginning to form naturally. Projects like the API Manifesto and the OpenAPI Specification have appeared organically, and aim to guide rather than create prescriptive or rigid frameworks that must be adhered to.

In fact, of the organizations they surveyed this year, SmartBear found that 69% of the were using the OpenAPI Spec, with only 15% using no standards at all in their API design.

Final Thoughts

We wouldn’t dream – or, at least, most of us wouldn’t… – of calling up or emailing a Python developer and telling them “you should be using JavaScript!” In addition to being incredibly rude, this makes all sorts of assumptions about the type of work they do and the space in which they do it.

That’s not a perfect analogy, since it refers to defined languages and we’re talking about API protocols here, but the basic premise is the same: the fact remains that some APIs are better-suited to certain jobs than others, and trying to tightly define standards in the space risks imposing limits that don’t need to be there.

Instead of focusing on pushing certain types of others it makes more sense to highlight the advantages and disadvantages of different API formats (something we’ve tried to do in the past). Best practices will inevitably, and organically, emerge for each type of API as their usage intensifies. Right now though, whatever the industry we’re talking about, REST is still the king.