And we probably need more.

APIs are growing worldwide at an exponential rate. Every day thousands of new businesses are releasing new APIs into the wild.

Javascript frameworks, serverless and microservices trends are creating ground for even more growth.

But when you look at developer experience level, it’s the Internet of 90ies. We have mainly repositories of APIs (aka RapidAPI) or so-called marketplaces (Heroku, AWS) that are not really marketplaces and have a terrible developer experience.

So, what are the main challenges around APIs for next years?

#1 Simplicity

Developers and organizations struggle to build solid APIs around their businesses because of the current complexity and layers of tools needed. If a company wants to launch public APIs they would need: API Gateway, continuous integration/delivery, rethink their IT systems in terms of isolation and security, provide billing and analytics, H24 support, a complete developers portal, and think ahead of usages.

So we need tools that automate and simplifies all of the repetitive tasks and provide a standard way of doing them.

The ideal journey to start a public API service should be :

• Open an account on a platform
• Create a service
• Push your GIT with business logic
• Publish your API

We try to achieve it with code.store.

#2 Standards

Google was possible because we had HTML and… language. Google was able to index the web because it used a standard content: language and standard way to present it: HTML.

With APIs, we neither have both. The content, the way APIs behave is a jungle where every single organization provides its implementation. Except for some few niches like authentication, it’s the wild west. And the presentation itself is not standardized: REST, SOAP, XML-RPC, GraphQL and many other ways.

We think that GraphQL is the language for APIs, everybody was waiting for.

#3 Testing & monitoring

At first, API automatic testing seems obvious, compared to the complexity of automatic functional testing of web UIs or mobile applications. But, even if we don’t have to deal with the complexity of analyzing DOM, there is no simple, standard way to test APIs.

But testing is not only about tools. It’s also completely intricated with procurement and providers management. If you work with Salesforce, SAP, and Adobe it’s easy to set up a legal framework with SLAs and penalties. You can set up a quarter’s review of your providers and try to apply penalties in case of repetitive failures. But what happens when you work with 200 small API providers?

We think there is a place for a platform that automatically tests, bills, and apply penalties based on specific SLA needs.

We want code.store to become such a platform.

#4 Documentation for humans… and machines

What does your API?

What objects does it manipulate?

What is persistent, what is not?

Clear documentation is key to rapid API adoption by developers. Companies like Stripe built unicorns partly because they were able to provide clear guidance for developers.

But we have now millions of end-points. With different ways to describe their APIs. Google can index their documentation, but we would need microdata or some kind of self-inspection on how one API works, not only what format it needs to function.

Again, we think GraphQL will bring most of it.

#5 Monetization

Billing initiatives are popping around API everywhere: RapidAPI, Apigee, and many other companies propose some billing solutions.

Easy monetization is key to the rapid adoption and growth of the eco-system. We should not be required to sign individual contracts with 100 API providers we wish to use.

What we need is a Stripe of API billing. It should be a worldwide, standalone billing and invoicing solution specifically designed for APIs. It should provide pay-as-you-grow, pay-per-call and all kinds of subscription-based billing. It would also manage payments and accounts. We should not be required to use their API Gateway or entire platform but only high-quality billing solution.

It might be AWS, or Google or Microsoft, or code.store :)

#6 Tech-savvy boards and CEOs

Companies providing data and digital products benefit from opening their APIs. But there is tremendous value in existing, brick & mortar industries if they release public APIs at all levels of their organization.

Think how valuable would be open APIs with data :

• air traffic, aircraft data from airlines
• geological data from oil companies
• recipes from famous restaurants
• realtime agricultural data for all species we grow worldwide
• towns providing data about subways, traffic lights or trash collection

Or APIs providing large companies’ know-how on some layers of their business :

• Walmart have probably unique systems to manage stocks and logistics, that they could sell as independent API first product
• Airbus could provide the most secured API first messaging system
• JCDecaux or ClearChannel could let you push advertisement trough APIs directly to screens on the 5th avenue.
• La Poste could let you perform some surveys by their postmen.

Things are moving forward, but we need CxO and boards of companies to be more tech-savvy and understand better how the digital world works.

Now, imagine we got all this. How the world would look like?

Let’s go on an imaginary user journey.

A romantic small boutique-hotel in Paris, La Maison Souquet wish to create a new product: a package for US honeymoon tourists. It would consist of their most beautiful suite, dinners in best Parisian restaurants, flowers every day, tickets to concerts and all transfers with a luxury black-car.

If they wanted to do it today, they would need a full-time employee managing all the bookings, or invest 100K$+ in the development of a specific solution, with at least a year of sourcing and negotiation with providers of different services. No ROI ahead.

But, in a world full of standard, public billable API and a Google of APIs it would require to :

• Hire a front-end developer to update their site (trough API?!)
• Add API from TheFork or OpenTable
• Add API from Accor hotels
• Add API from Mercedes-Benz
• Add API from Fnac Concerts (for Parisian events tickets)
• Add API from Monceau Fleurs (french flowers shops)

And to perform those tasks, the front-end developer would be autonomous. No need to contact sales, sign contracts, setup platform-specific technological stack or SDK, dig long hours into API documentation or check for the quality/completeness of API itself. They could browse available services, prices, and set up their projects without involved providers even aware of how their services would be used by Maison Souquet.

This article was originally published by Maxime Topolov on medium.