Search results

API reference tutorial overview

In this API reference tutorial tutorial, we’ll work on creating five common sections in REST API reference documentation: resource description, endpoints and methods, parameters, request example, and response example.

For context, we’ll structure the information from the sample new endpoint to document into these five sections.

Five common sections in REST API docs

Almost all API reference topics include these five sections:

1. Resource description
"Resources" refers to the information returned by an API. Most APIs have various categories of information, or various resources, that can be returned. The resource description provides details about the information returned in each resource. The resource description is brief (1-3 sentences) and usually starts with a verb. Resources usually have a number of endpoints to access the resource, and multiple methods for each endpoint. Thus, on the same page, you usually have a general resource described along with a number of endpoints for accessing the resource, also described.
2. Endpoints and methods
The endpoints indicate how you access the resource, and the method used with the endpoint indicates the allowed interactions (such as GET, POST, or DELETE) with the resource. The endpoint shows the end path of a resource URL only, not the base path common to all endpoints. The same resource usually has a variety of related endpoints, each with different paths and methods but returning variant information about the same resource. Endpoints usually have brief descriptions similar to the overall resource description but shorter.
3. Parameters
Parameters are options you can pass with the endpoint (such as specifying the response format or the amount returned) to influence the response. There are four types of parameters: header parameters, path parameters, query string parameters, and request body parameters. The different types of parameters are often documented in separate groups. Not all endpoints contain each type of parameter.
4. Request example
The request example includes a sample request using the endpoint, showing some parameters configured. The request example usually doesn’t show all possible parameter configurations, but it should be as rich as possible with parameters. Sample requests sometimes include code snippets that show the same request in a variety of languages (besides curl). Requests shown in other programming languages are optional and not always included in the reference topics, but when available, users welcome them.
5. Response example and schema
The response example shows a sample response from the request example. The response example is not comprehensive of all parameter configurations or operations, but it should correspond with the parameters passed in the request example. The response lets developers know if the resource contains the information they want, the format, and how that information is structured and labeled. The description of the response is known as the response schema. The response schema documents the response in a more comprehensive, general way, listing each property returned, what each property contains, the data format of the values, the structure, and other details.

Tutorial workflow map

The topics include a workflow map to help guide and orient you each step of the way.

After the tutorial

When we’re finished, the end result will look like this. You’ll then have an opportunity to create an API reference topic with your own open-source API project.

Although there are automated ways to publish API docs, we’re focusing on content rather than tools in this section. In the Publishing your API documentation section, we’ll jump into publishing tools and methods.

Next steps

Now that you have an idea of the tutorial, let’s get going with the first section: Resource description.

23% Complete

23/101 pages complete. Only 78 more pages to go...


If you would like to contribute back to say thank you for the API documentation course, click the Donate button below. Alternatively, to contribute content, such as a tutorial or a new section, contact me with your ideas. You can also submit a pull request in the GitHub repo to make your contribution. Even if you want to just fix a typo or add a sentence here and there, it's always welcome.

Get new posts delivered straight to your inbox.

Subscriber count: 4,285