Best Practices Guide for Documenting RESTful Services

This guide provides a set of best practices that will help you with the task of documenting a RESTful web service.  These best practices were established by the developers at Adivo who have extensive experience in technical documentation, web services design and development.

Start With a Good Web Service Design

A good design can make documenting your RESTful service a much easier task.   Although it might not always be an option, if you have any influence over the design, here are some key areas that you should look out for:

  • Naming conventions - The lack of naming conventions can result in very inconsistent and cryptic names for the methods and parameters exposed by your web service making it more difficult to document them properly.  Applying good naming conventions to the web service API will promote better readability of the documentation.

And even if you do not have any control over the design, a quick review will help you better estimate how much time it will take and set expectations for the completion of the documentation.

Describe Your RESTful Service API

To document your RESTful service, you should describe the following web service components:

  • Methods - Methods are typically named as verb phrases that denote some type of operation or process that the method performs.  To document the methods, describe what that process does.
  • Method Arguments - Methods can have zero or more input arguments and zero or more output arguments. For input arguments, describe what the argument represents and how it is used by the method. For output arguments, describe what the argument represents and how it was provided by the method.
  • Schema Components - Schema components such as elements and types are used to define input and output arguments. While some arguments may be defined by simple types like strings and numbers, other arguments may have a complex structure defined by a schema element or type. Providing descriptions of the schema components used to defined arguments allows you to document the structure of those arguments.

The descriptions for these web service components should be concise and consist of one or two sentences.  If there is additional information that is important to document, you should consider structuring your comments into two parts: a summary description followed by a remarks section.  The remarks section can be used to include the additional information.

To create your descriptions and remarks use a tool like TechWriter to annotate the RESTful service with external comments that can be used to produce the complete documentation.

Use a Documentation Generator

Creating documentation for a RESTful web service can be difficult because the API is not explicitly defined. Fortunately there are tools like TechWriter that can be used to generate the web service documentation automatically, deriving the web service definition from sample requests and resposne, and applying the external comments that you created.

Make Documentation Part of Your Development Process

If your project is using automated build tools like Ant, NAnt and MSBuild, you can make generating the documentation part of the automated build process for the system.   By having the documentation as up-to-date as the system itself, your project will benefit in the following areas:

  • Knowledge Capture - While some development methodologies such as Agile ascribe to a "document late" philosophy, projects can suffer greatly when they lose a team member.  The knowledge of a system literally walks out the door.  Documenting as you go minimizes the impact of losing a team member and makes it easier for new team members to ramp up.
  • Communication - Documentation can help communication among project team members.  The project manager can better assess the status of the project.  Subject matter experts can verify that developers are on the right track.  And mistakes can be identified earlier in the project life-cycle.
  • Documentation Quality - Scrambling at the end of the project to throw the documentation together for the final deliverable can result in the API not being documented properly, if documented at all. 

By making documentation part of your development process you will ensure that the documentation is always in sync with the API, even in extreme programming environments where the API is constantly changing. 

For more information please visit: