New! Public style guides are available for Professional and Enterprise workspaces. Simply login to your workspace, click on the Governance tab, and look for Public Style Guides, then enable the rules you want to use. Public Style Guides are sets of curated rules from top companies around security and design themes. API Program leaders can implement these preset style guides with a few clicks. Use Public Style Guides to inform your own API style guides and tweak the rules according to your needs, or enable a preset guide to use out-of-the-box best practices in your Stoplight projects. Sign up here to get notified about the latest Public Style Guides release
API style guides, or API guidelines, are easy-to-consume references and instructions for all of the important information that a team will need to create or work with APIs. The style guide gives specifics about functions, classes, return types, errors, arguments, and more, and can be used to enforce standardization across an API program.
This API style guide reference will help give you a basic understanding of API guidelines, what they are, and best practices for how to create, use, and enforce them at your organization.
If you asked 100 developers which naming conventions to use where in an API spec, you’ll either get 100 answers or an all-out brawl. To save this from happening, most API teams that grow beyond a handful of developers will implement a style guide.
Also known as "API Design Guides," "Design Guidelines," "Style Books," or "API Standards," the simple concept of "make a bunch of decisions and write them down" has helped API teams for decades be more consistent, develop faster, and create better APIs.
These style guides might contain rules about how to handle versioning, filtering, error formats, naming conventions, pagination, or any of a million other variable parts of an API, helping take the burden off of teams about making those different decisions.
An API style guide ensures everyone on the team follows basic API design patterns.
But the real benefit is for your developer experience. API consistency equals predictability, and it makes it easier for internal and external developers to work with your APIs. When your API is delightful to use, adoption and retention increase.
Remember: customers that build products using your API are stickier than those who don’t. As more teams within the customer’s company continue to integrate with the API, the better prepared you are to expand.
For your API style guide to be most effective, it should cover several common API design themes and be written in a way that is:
- Easily Updated
According to an excellent article by Nordic APIs on the best practices for creating an API style guide, here are some of the common design themes you should include in your API style guidelines.
One of the first points to cover in your API guidelines is defining the overarching architectural style. Should your organization or team follow REST, GraphQL, or a different design pattern?
In addition, you’ll want to let developers know whether they should be describing their APIs with some kind of specification (hint: they probably should), and if so, what that specification is.
One important aspect of API design is security. In addition to design style, security should be one of the major themes in your style guide. In particular, style guides should explain how developers should implement authentication and authorization.
Some of the top authentication frameworks include:
- Basic Auth
- OAuth (1)
- OAuth 2.0
- OAuth 2.0 Password Grant
- JSON Web Token (JWT)
Usually, OAuth 2.0 is the industry-standard protocol for authentication.
Endpoint naming can sometimes be underlooked in API design. They’re important because they often remain associated with the API and can even be more widely used. That’s why you should dedicate a section of your API style guide to naming conventions. Keep them simple, universal, and consistent.
Consider HTTP error codes as another critical component of your API guidelines. Though they don’t vary too much, you should still include specific error codes in your style guide.
Versioning and breaking changes and how to treat them can vary between organizations. Be sure to highlight how to treat versions and breaking changes in your API guidelines, and update this section as your versions evolve.
Define the units, formats, and standards that developers should follow in your API style guide. What to define can depend on your industry, but “some types of data — like date-times — are relatively universal.”
[Source: 11 Tips for Creating an API Style Guide]
Now that you know what to include in your API guidelines, here are some best practices for creating excellent style guides that your organization will adopt, contribute to, and want to use.
Create an easy-to-consume style guide that is brief yet thorough. Developers should be able read the entire style guide, but it should also be comprehensive enough to provide consistency for even small considerations.
One way to create a more comprehensive style guide is by, “frequently linking to external resources, where specific standards or best practices are described in more depth. These can be your organization’s own resources or even trusted third-party resources.”
One of the best ways to illustrate and show an idea is to include an example. Build in sample requests and responses throughout your style guide. Sometimes it helps to include several requests and responses to show how developers should—and should not—design their APIs.
Work across your team to collaborate on your API style guide. Encourage developers to submit feedback or request help on their API designs. Cross-team collaboration will improve buy-in and increase adoption of your guidelines.
Evangelizing your API and style guide with the developer community can also help enforce consistency. This helps showcase the thought you’ve put into your API and helps you get good feedback from those using your style guide.
[Source: 11 Tips for Creating an API Style Guide]
One major way of enforcing API style consistency is by using automated tooling to ensure the same pattern is applied in a scalable way across all your APIs. Rather than implementing this manually, you can use tooling to automatically apply API standard guidelines, which are a set of objective rules that define how the API should operate.
While maintaining consistency via manual updates can sometimes be useful, Stoplight comes with automatic linting which allows you to create and automatically apply rules for common occurrences in your API.
By default, linting is done based on a pre-defined ruleset. You can add additional rules specific to your organization by creating a custom style guide. Some example rules can be:
- Enforce having at least one global security scheme
- Warn against using an authentication except for OAuth or missing descriptions
- Recommend having at least one error for Endpoints
These rulesets give you the ability to define and promote consistency across your organization automatically with flexibility.
In the end, establishing and producing a consistent Style Guide is crucial to developing a successful API. You want customers to work with you and use your APIs because you help them solve problems. In order to make it easy and delightful to work with your APIs, you need proper documentation, an easy and predictable process, and a strong rally around consistency.
- Introducing Style Guide Projects in Stoplight Platform
- Consistent API URLs with OpenAPI
- Automating API Design Guidelines
- Automated API Design Checks in CI
- API Style Guides Through the Ages
- Example Style Guides We Love
- Automated Style Guides: Linting, Versioning and More
- 11 Tips for Creating an API Style Guide (Nordic APIs)
- A Practical Guide to API Design-First (Stoplight)
- Style Guides - Stoplight Platform Documentation (Stoplight)
- How to Create Quality and Customer-Centric APIs (Stoplight)
- 7 (Not So Deadly) Steps to Create a Successful Developer Relations Program (Stoplight)
- An Overview of API Authentication Methods (Cloud Elements)
You can also check out Stoplight’s open-source linting tool, Spectral, to help you create further consistency and standardization in your API program. Spectral is a linter that allows you to create style guides for your structured data. Things like OpenAPI/AsyncAPI/RAML descriptions, Kubernetes config, GitHub Actions, you name it, Spectral can help you lint it.