![]() In case that attributes need to be explained, like language codes with extensive tables, take care that these are included by reference and are maintained on a central location. Take care that every attribute is explained. ![]() And, expand from there towards the general structure of API calls. Therefore, start with a code example that does the job for one Open Icecat data-sheet. Make it as easy as possible for a user, new to the field, to make use of the API that you describe. Like any text, have it been checked by a native-English speaker, before publishing it. Make complex stuff simple, so that even non-techy outsiders can understand what it is all about, if they would skip the code sections. So, take care that your manual is written in clear and understandable English “for Dummies”. Further, an API Manual is not only read by developers, but also by all kind of other staff. Use English “for Dummies”ĪPI manuals should be in English. Take care to first read the Iceclog Editor Guidelines, as they are an integral part of these more specific guidelines. A good specification reads like a manual, and writing the final manual is the final check on the specifications of an API from a usability point of view. But also the specification of APIs that Icecat is providing to its users. This Icecat API Manual Guideline is written to help to increase the usability and consistency of the manuals. ![]()
0 Comments
Leave a Reply. |