DEV Community

Cover image for Why your API Doc Structure Matters: How these 5 Principles make it easy for your readers
Rijul Rajesh for Hexmos

Posted on

Why your API Doc Structure Matters: How these 5 Principles make it easy for your readers

Common Issues with API Docs: And How I Managed to Solve Them

Good API Documentation is crucial for developers to understand and utilize the APIs in the best way possible, And it can contribute to the success of the project.

A Project without good documentation is like a tool without proper instructions. No matter how good the tool is, if people don't understand, it's useless. So we need a proper idea of what common mistakes people commit when making API documentation for their project.

alt text

1. Discovering the right API that I need

When a developer enters your documentation, they will usually have an specific goal in mind. They will be searching for an API which they need from your documentation.

Example: Suppose your API docs includes an endpoint for sending emails
If the developer searches with "email" then the relevant endpoint should come up right away.

If the API Documentation has poor search functionality and unorganized documentation structure, the developer can get exausted trying to find the API they need.

The solution towards this problem is to implement a proper search functionality as well as a documentation structure.

Divio has a good structure that helps to easily grasp the contents.

alt text
This system divides documentation into 4 main types

1. Tutorials (Learning Oriented): Designed to teach, help a developer to acheive something from start to finish

2. How-To Guides(Problem oriented): Helps to solve a particular problem step by step

3. Explanations (Understanding oriented): Provides in-depth explanations about how things work

4. Reference(Information oriented): Serve as a technical resource if you need specific details

2. Figuring out how to use it

When API documentations are made, We can often forget that this documentation is meant to be read by a developer who has no prior experience working with the system. So the they can often be left wondering what the endpoint does and what is the bigger picture in which this API belongs.

To solve such issues, we need a detailed description, which should be beginner friendly, and should demonstrate real-world usecases

Example:
Suppose the following API is shown in the documentation:

https://dogapi.dog/api/v2/breeds/{id}
Enter fullscreen mode Exit fullscreen mode

The user might not immediately know what the API does or what value to insert for {id}.

To resolve this, the documentation needs a clear description and a real-world example, like:

The API (https://dogapi.dog/api/v2/breeds) provides detailed information about various dog breeds. This API allows users to retrieve specific data related to dog breeds, including attributes like name, physical characteristics, life expectancy, weight, temperament, and other related details.

https://dogapi.dog/api/v2/breeds/68f47c5a-5115-47cd-9849-e45d3c378f12
Enter fullscreen mode Exit fullscreen mode

3. Procrastination in creating the code and getting it done

Even if the documentation is well-defined, the developer may still feel some friction in integrating the API into his code. As a solution to this problem, we can have code snippets in various languages that can be generated from the API.

The developer can directly copy and paste these snippets into his code and get things running quick.

For example
A python developer will prefer a ready made request like

import requests

url = "https://dogapi.dog/api/v2/breeds/68f47c5a-5115-47cd-9849-e45d3c378f12"

response = requests.get(url)

print(response.json())
Enter fullscreen mode Exit fullscreen mode

Rather than a plain url

https://dogapi.dog/api/v2/breeds/68f47c5a-5115-47cd-9849-e45d3c378f12

4. Handling Errors and Authentication

Imagine a new developer who is using your API encounters an error or faces an issue related to authentication.The first place they would look is your Documentation, to see what are the possible errors and the solutions which can be applied.

But if the documentation doesn't have such information, then the whole debugging process can become painful. This can even lead to the user ultimately dropping off from your API and searching for easier alternative solutions.

We can solve this problem by listing the common errors, showing detailed troubleshooting solutions and link towards how the authentication tokens are to be obtained.

For example:

Imagine a developer trying to access a protected API endpoint, but faces errors.

The API docs should demo how to use the authentication token like

curl -X GET "https://httpbin.org/bearer" \
-H "Authorization: Bearer YOUR_ACCESS_TOKEN"
Enter fullscreen mode Exit fullscreen mode

And show the possible errors like so.

Error Code Error Message Troubleshooting Tip
401 Missing Authorization Header Ensure you include the Authorization header with the Bearer Token.
403 Invalid or Expired Token Verify that the token is valid and has not expired.
500 Internal Server Error Try again later, or contact support if the issue persists.

How Mainstream API Docs Structure Information for the Readers: A Case Study

Mintlify

For our Mintlify example, let's visit the infisical documentation.

Suppose, I want to look for an API for Creating Client secret. There are 2 ways in which I can access it. One is to go through the Auth-related categories and find them. Or I can use the search bar and search for "Client secret". It's pretty straightforward to get the APIs we need.


Since we got the API we need, We need to understand it next. Details are provided related to Authorizations, Path parameters, Body, and Response.

Now we have understood the API. The next thing to do is get the implementation done. We have the code snippets in various languages (cURL, Python, Javascript etc) as well as the responses to see what it looks like.

Readme

Let's explore the Readme documentation.
We will be visiting persona documentation for this.

image
The UI consists of a sidebar and a topbar. We can see the Topbar having OpenAPI Spec, which is a standard format for defining RESTful APIs, allowing for clear documentation and interaction with the API. This also means the documentation is synced with the OpenAPI Definition, ensuring the details in the documentation are always upto-date.

There is an API Changelog as well, so each changes are tracked.
image

Suppose we want to use the Create Authorization API. I can either go to the OAuth section or the search bar to get the API.

image

To understand how the API works, I can utilize the "Try it" button to run the API myself and observe what the output looks like.

For deeper understanding, we have sections like Form-Data, Headers, and Responses.

We can also observe an Alert, which informs the user about the prerequisites.

Fern

At last, we can check the Fern Documentation.
We will be visiting Vellum documentation.

We will try searching for Execute Prompt API. This API can be similarly accessed via the search bar or the sidebar.

image

For understanding the API, we have a play button to try the APIs ourselves as well as some description about the Request and Response.

Based on our learnings, we now know the features that these API Documentation platforms use. Let's go through it one by one.

The Key features that improve Developer Engagement

Read the remaining article

Top comments (1)

Collapse
 
richmirks profile image
Richard Mirks

It's really helpful to see a breakdown of API documentation best practices! Could you provide more details on how to balance simplicity with being detailed enough for both beginners and experienced developers?