This guide provides a set of best practices that will help you with the task of
documenting a 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 web 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
- Global components - Some web service definitions allow the schema components that
are used to specify method arguments to be defined either
locally within the parent component or globally so that the component can be reused. By
using global components in your web service, you will maximize reuse and reduce the
number of components that you need to document.
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.
Embed Comments inside Your Web Service Definition
Most web service definitions provide a mechanism for adding comments to methods, arguments
and schema components. These comments are included as part of the web service definition
making them easy to maintain as the web service API
changes over time.
By embedding comments inside your web service definition, you create a
"self-documenting" design that will be easier to understand.
Comment What You Can and Annotate Everything Else
Depending on the commenting capabilities of your web service definition, you should add
comments to 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. When you add comments to 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 that you add to 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.
Not all types of web services will have commenting capabilities robust enough to handle
documenting all of the web service components mentioned here. To get around these limitations,
you can use a tool like TechWriter
to annotate the web service with external comments that can be merged together with
the embedded comments to produce the complete documentation.
Use a Documentation Generator
Having a self-documented web service is helpful for web service design and maintenance,
but there are many instances where you are going to need actual API
documentation. Here are a few examples:
- Design Documentation - If you are creating a web service for a client,
design documentation is typically a required deliverable.
- Web Service API Documentation - While your web service developer may have
the knowledge and expertise needed to read and understand
the web service definition, developers that wish to make calls to the web service API may not.
You will need to provide these developers with some form of documentation that
will help them use the API.
- Design Reviews - Not all participants in a design review are going to
have the same level of web service knowledge and expertise. Your subject
matter experts may not be technical at all. To facilitate such a design
review, you will need to provide documentation that anybody can read and
Fortunately there are tools like TechWriter
that can be used to generate the web service documentation automatically, leveraging the web service definitions
and the comments you've embedded.
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 web service API, even in extreme
programming environments where the API is constantly changing.
For more information please visit: