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 Quarksoft, LLC 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:
