如何做到API文档规范化
定义一个好的 API 文档是优秀研发人员的标准配置，在执行接口测试之前，测试人员一定会先拿到开发给予的接口文档。
测试人员可以根据这个文档编写接口测试用例，优秀的文档可以区分好的用户体验和坏的用户体验。它不仅可以帮助优化工作流程，还可以帮助前端工程师和测试工程师更好的规划自己的任务。作为一名互联网程序员，我们应该学习如何高效的输出一份优秀的 API 技术文档。
首先我们需要了解接口文档的主要构成及含义，完整的接口文档有公共信息说明、请求响应、接口签名 DEMO、加签代码示例、接口功能说明、接口参数详细说明 5个部分组成。
1、公共信息说明：
公共信息说明页为公共参数说明及请求受理结果代码两部分：公共参数说明填写多个接口提取的通用参数，这里可以分为请求参数及影响参数。需要填写参数名称，类型，最大长度，描述和用法。请求受理结果代码就是影响码的说明。
2、请求，相应及加签 DEMO
请求，响应及加签 DEMO 页，一般这个页面会描述加签的过程，例如分为 rsa 加签私钥和服务参数说明。服务参数需要进行以下说明:
-
对参数名进行从小到大的排序
-
对参数及参数值拼接成字符串
-
用 RSA 对参数串进行加签后用 base64 编码，获得签名串
-
对各个参数值进行参数值特殊字符的转义
-
请求体说明
3、加签代码示例
加签代码示例部分会填写加签的代码实例，测试人员可以根据加签代码编写测试代码。
4、接口功能说明
接口功能说明填写各接口的重要信息，包含借口名称，接口类型，接口服务代码，接口版本号，备注。
5、接口参数详细说明
接口参数详细说明填写接口的主要信息及参数信息。主要信息有服务名称，服务代码，服务版本号，服务功能描述，服务提供方系统，服务消费方系统。参数说明可分为描述，类型，子段长度，是否必填，说明。
通过以上我们可以读懂接口文档也是接口测试的重要环节。通过对工作中接口文档的详解，指导测试人员如何理解接口文档，进而通过接口文档编写接口测试用例。
API 文档的重要性
API 文档是人类和机器可读的技术内容，用于解释特定 API 的工作原理及其功能。它的目的是双重的。如果做得正确的话，API 文档将成为 API 工作方式的一个真正信息来源。它应该以结构化格式包含函数、参数、类等的详细信息，便于开发人员和非技术用户理解。通常，它包括教程和示例，帮助用户更好地理解不同部分如何协同工作。
由于有许多不同类型的文档，很难使事情井然有序。API 需要参考、指南和其他内容来帮助开发人员。另外 API 支持的产品可能需要自己的参考资料，包括屏幕截图和视频。
什么是好的 API 文档？
一个好的 API 文档，除了内容合理详细之外，它的样式和交互方式也要简单易用。现在的 API 文档基本基于网页来展现，利用网页的显示特性，有一些比较常见的设计方式。在这里推荐一些适合作为 API 文档展现要素的一些最佳实践。
许多流行的工具在线发布他们的 API 文档，以便第三方开发人员可以轻松访问它们。以下是这些文档如此有效的一些原因：
-
在文档中提供了示例代码，以便用户可以看到API在实践中是如何工作的
-
轻松找到常见问题的解决方案，以便忙碌的开发人员可以快速获得所需的内容
-
不提供理解 API 及其工作方式之外的不必要信息。当用户忙于工作并遇到问题时，他们需要可用的文档，而不是无关的信息
-
不需要设限知识水平；最简单的概念和最困难的概念一样得到充分解释
格式良好。内容有条理且一致且易于阅读。这减少了希望学习或解决问题的用户的摩擦。
文档的工具要求
想要一个工具来处理所有类型的文档是很自然的。考虑 API 文档，通常需要与工程团队协作。将API文档硬塞进帮助文档平台可能行不通。工程团队处于版本控制中，例如 Git，因此即使是复制粘贴到 CMS 的手动过程也无法完成。随着工程对 API 进行更改，文档需要随之更改，生成 API 参考将确保避免许多潜在的麻烦。
最佳的编写方式
编写 API 文档的方式不仅一种，不同的软件有不同的使用规范，这些规范都各自提供了描述 API 的不同标准和风格，以下三四种仅为参考：
-
OpenAPI（以前称为 Swagger）–最受欢迎的规范。开源，并得到 Microsoft 和 Google 等公司的支持。使用具有特定架构的 JSON/YAML 对象来描述 API 元素。
-
API Blueprint 另一个开放源代码规范，API 蓝图旨在提供高度可访问性。它使用类似于 Markdown 的描述语言，并且在 API 创建过程中遵循设计优先原则的情况下表现出色。
-
RAML–基于 YAML 的 RAML（或 RESTful API 建模语言）采用自上而下的方法来创建清晰，一致和精确的文档。
-
Eolink Apikit 以服务形式存在的接口文档，它可以伴随代码的变更同步变化，这就减少了很多开发工程师和测试工程师之间的沟通成本。
这些编写方式都可以应用于目前的工作，简单、有?、可发现、?致、可预测，所有这些不仅描述了良好的 API，还描述了良好的产品。这不是偶然的，当你编写 API 时，你将创建?个产品。
API 文档的可维护性
对于 API 文档的可维护性应该保持像维护一个单独项目一样，每次通过分支的形式进行更新，编辑人员在检查文档内容的正确性和简介性之后，并由项目组成员进行 review。当 API 文档发布后，后期维护也是同等的重要，主要体现在两个方面：
-
New feature 和废弃功能；当发布新功能之前应该先发布文档，并保证文档通过了标准的review 流程。然而废弃掉的旧功能从文档中移除，并建议在对应的位置给出废弃功能提示和升级指南，确保使用旧功能的开发者进行升级工作
-
在文档页面上应该预留文档的 contribute 入口，如果文档托管在 GitHub 这样的平台上就提供指向仓库的链接，方便每个阅读文档的用户给文档提 Issue 或者 PR。如果文档是闭源的，也应该至少留有提供反馈信息的位置
关于一些可用性建议
作为开发?员，我们很容易忽视这?点。根据知识的偏差，假设我们的 API ?户是程序员，他们知道我们所知道的，理解我们所理解的，但我们并不认为他们是最终?户或客户。要克服这种偏差，换位思考是设计好的 API 的关键思想。所以当你编写下?个 API 时，把??放在客户的?度，想象你想要的是什么。
以上是对项目开发合作中写出友好的 API 文档的一些想法和建议，欢迎讨论。