APIs are driving digitalization and have been more than a buzzword throughout industries. However, implementing API standards is a challenge for enterprise as there are many different definitions and interpretations of what a proper RESTful API entails. Recently SmartBear released a study The State of API, where they surveyed over 3,000 developers, architects, product managers, operations and QA professionals from around the world and the biggest challenge by consensus is: standardizing APIs.
A common approach to standardizing APIs within an organization is to assemble a team of API experts (architects, developers, etc.) and have them put together comprehensive API Guidelines. This is a great initiative and leads teams to ask important questions and implement rules to ensure that the APIs are both secure, usable and scalable. However this is can quickly evolve into a massive undertaking.
API standards must also be respected
If we take a look at Zalando, the Europe’s leading online fashion platform with more than 15,000 employees, they have released their RESTful API Guidelines on GitHub and can be read here: Zalando RESTful API and Event Scheme Guidelines. These are an excellent example of API guidelines, as they explicitly dictate how RESTful APIs at Zalando should be developed and provide examples, suggestions as well as strict must and must nots.
Back when these API Guidelines were written (they were published on GitHub in January, 2016), Zalando employees put an immense amount of effort into crafting these RESTful API Guidelines and if you haven’t checked them on GitHub, they available as a 96 page PDF.
While their efforts should be applauded for putting together a 96-page master-piece, the real work is then ensuring that the guidelines are enforced across all of their apps and microservices. Having such guidelines is important, however enforcing them across an enterprise – especially one that is operating on a global scale – can be nearly impossible.
Simply understanding or knowing the majority of the guidelines listed in the 96 page document is a challenge. While this may have been a key factor of success for Zalando as they were starting to scale up and deploy their microservices architecture on AWS and other clouds – most enterprises are not this digitally mature, and may never be.
Luckily, it’s 2019 and the world of APIs has matured, best practices have been published by leaders such as Zalando and standards such as the OpenAPI Initiative are gaining popularity and adoption.
At ApiOmat, we’ve been strong pundits of standardizing APIs as a defining requirement to successfully scale into a digital business. Since 2012, ApiOmat allows users to generate standardized RESTful APIs. By using ApiOmat, teams can quickly define their API end-points and focus one what’s important – solving a business problem.
By abstracting the actual creation of the API and automatically implementing the OpenAPI Initiative standard, teams can deliver results faster without having to leaf through a 96 page API Guidelines to double or triple check that their product fulfils all the requirements. Additionally, companies no longer have to enforce the guidelines across internal and external development teams or system integrators.
To demonstrate how quickly you can create an OpenAPI Initiative conform API, I made a recording to show how fast we can have a new API up and running. https://www.youtube.com/embed/VQ_-liekjxE?enablejsapi=1&origin=https%3A%2F%2Feasy-software.com
Creating a new API this quickly provides companies with the agility to rapidly create MVPs and rapid prototypes to validate use-cases. With ApiOmat, you can also decouple the frontend from the backend development – allowing frontend developers to work with the generated API while backend developers can add their logic, integrate data sources and aggregate data from multiple sources.
A strict API standard can meet almost any business use case
With every rule, there is always an exception and strict API standard may not fulfil every business use-case – however it is likely to solve a majority. If a project requires a specific protocol that does not adhere to a RESTful API standard, such as GraphQL, then those can be address individually. For the majority of use cases a standardised RESTful API will do the job.
Feel free to contact us if you want to learn more about APIs and standards.