Tags
Updated reflecting changes discussed in blog post: Making Scripts Work with IDCS Deployed PaaS
The last week or two I have been working on a new API Platform utility to add to my existing tools (see here). This tool addresses the question of generating documentation. Much as been said about API documentation and the quality of it, check out these articles :
- https://nordicapis.com/the-easiest-ways-to-generate-api-documentation/
- https://dzone.com/articles/best-practices-in-api-documentation
If you look at these articles and others, there are some common themes, which are:
- Document the URI / payload
- Describe error handling
- Describe contracts such as how many API calls
- How the API is authenticated
Apiary covers the first theme to a first class standard, and you will see Apiary called out for its ability to document APIs in a lot of articles. Well written API Blueprints will cover the bulk of the second bullet. But the other points tend to fall outside of a Blueprint and fit more the API Policies and their use.
Not everyone is so commited or enjoys writing documentation. The other driver for going beyond the use of Apiary is that some organizations feel the need to have a traditional word style document to capture/define an API’s contract in detail. With the API Platform the management portal enables an API to be published into the developer portal with the Apiary definition and a markdown file for further documentation.
