接口文档设计（接口文档设计教程）

本篇文章给大家谈谈接口文档设计，以及接口文档设计教程对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享接口文档设计的知识，其中也会对接口文档设计教程进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、什么是接口文档,如何写接口,有什么规范?
• 2、前后端分离，关于接口文档，后端是要先写好接口文档，再进行写代码开发，还是写完代码后再编写接口文档？
• 3、用了Swagger2后，接口设计文档，测试用例都不用自己写了，爽
• 4、API接口入门（一）：读懂API接口文档
• 5、Restful接口文档规范
• 6、软件接口说明文档怎么写

什么是接口文档,如何写接口,有什么规范?

含义是：在项目开发中接口文档设计，web项目的前后端分离开发接口文档设计，APP开发，需要由前后端工程师共同定义接口，编写接口文档，之后大家都根据这个接口文档进行开发，到项目结束前都要一直维护。

目的是：项目开发过程中前后端工程师有一个统一的文件进行沟通交流开发。项目维护中或者项目人员更迭，方便后期人员查看、维护。

规范是：以/a开头，如果需要登录才能调用的接口(如新增、修改接口文档设计；前台的用户个人信息，资金信息等)后面需要加/u，即：/a/u接口文档设计；中间一般放表名或者能表达这个接口的单词；get方法，如果是后台通过搜索查询列表，那么以/search结尾，如果是前台的查询列表，以/list结尾；url参数就不说接口文档设计了。

API（Application Programming Interface，应用程序接口）是一些预先定义的接口（如函数、HTTP接口），或指软件系统不同组成部分衔接的约定。用来提供应用程序与开发人员基于某软件或硬件得以访问的一组例程，而又无需访问源码，或理解内部工作机制的细节。

应用程序接口又称为应用编程接口，是一组定义、程序及协议的集合，通过 API接口实现计算机软件之间的相互通信。API 的一个主要功能是提供通用功能集。

API同时也是一种中间件，为各种不同平台提供数据共享。程序设计的实践中，编程接口的设计首先要使软件系统的职责得到合理划分。良好的接口设计可以降低系统各部分的相互依赖，提高组成单元的内聚性，降低组成单元间的耦合程度，从而提高系统的可维护性和可扩展性。

前后端分离，关于接口文档，后端是要先写好接口文档，再进行写代码开发，还是写完代码后再编写接口文档？

1、先理清业务流程
2、定义前后端开发的接口规范。比如json的格式，url的格式
3、定义接口文档，这里的接口文档一般就是对应后台的实体reqVo（调用后台接口<控制器访问的实体）和返回给前台的respVo（前台调用接口的返回的实体）。注意一般respVo都会有在后台做一个统一的处理为ResultVo（这个规范在2中要定义好，比如：错误码，错误描述，请求的url，请求时间，以及实体T<这个实体才是真正的respVo和业务相关,这个一般都是实体）
4、定义接口文档是在了解业务流、数据流基础之上完成的。有了这个接口文档（其实就是定义实体的过程和对应的json）前后端的开发基本按照这个文档去开发。接口文档会有版本迭代，一般放到svn上，供所有开发人员阅览
5、现在一般系统用到的数据库都不会是单纯mysql了。还有redis，mongo、es等。这些个人感觉都是在十分了解业务的情况和系统架构下去设计的。后台运用这些工具去完成接口功能的实现已经系统功能和性能的实现。这个和接口文档先后顺序还真不好说，个人觉得都可以。
6、业务流-数据流-资金流。去了解和设计系统。

用了Swagger2后，接口设计文档，测试用例都不用自己写了，爽

pom文件加入如下依赖

启动类上加入@EnableSwagger2注解

增加配置类

访问http://localhost:8080/swagger-ui.html

取其中一个例子，示例返回以及要填的各种参数都已经帮你弄好了，直接填入参数就能测试，非常方便

导出文档

可以将测试页面导出为各种格式的文档，不再介绍

Swagger注解

可以用Swagger提供的注解，对显示在页面的上的各种参数进行描述，和代码耦合性比较高，不再演示

@Api：修饰整个类，描述Controller的作用

@ApiOperation：描述一个类的一个方法，或者说一个接口

@ApiParam：单个参数描述

@ApiModel：用对象来接收参数

@ApiProperty：用对象接收参数时，描述对象的一个字段

@ApiResponse：HTTP响应其中1个描述

@ApiResponses：HTTP响应整体描述

@ApiIgnore：使用该注解忽略这个API

@ApiError ：发生错误返回的信息

@ApiImplicitParam：一个请求参数

@ApiImplicitParams：多个请求参数

API接口入门（一）：读懂API接口文档

本文目录：

API接口是什么？

为什么我们需要API接口？

API接口接口文档设计的核心

一、API接口是什么？

我们来以一个常见的数学公式理解API，比如y=x+2，当x=2的时候，y=4，对么？

那此时，我们把y=x+2称为接口，x=2称为参数，y=4称为返回结果，那这个接口的功能就是能把我们输入的数加上2（注意：这里接口文档设计你可以发现接口自身是带有逻辑的）。

类比地，我们来理解一个常见的场景，比如现在有一个可以把经纬度转化为城市的接口，那当我输入经度是55°，纬度是88°的时候，接口通过自己的逻辑运算，返回结果告诉我：杭州市。

这样接口文档设计你就可以清晰地了解百度百科的官方解释了，接口就是预先定义的函数逻辑，他是供其他系统请求，然后返回结果的一个东西。

二、为什么我们需要API接口？

背景：我们的业务系统涉及多方多面，如果要一个公司或者一个系统把所有业务都做完，那未免工作量太大了吧？并且如果其他系统或公司有更好的运算逻辑，那我们在设计功能的时候可以考虑利用接口进行开发。

核心需求：利用现有接口可以降低开发成本，缩短开发成本。

举个例子：比如我是打车的APP，现在我需要在我的页面上展现地图的功能，对于我司而言，新做地图功能未免成本过高，那我们可以在高德开放平台或者百度地图的开放平台，找到地图API，这样的话我们只需要购买高德的服务，部署调用高德地图API，这样就可以快速在我们页面上线地图功能了。

三、API接口的核心

对于小白而言，初看API文档可能是一头雾水的——从哪里看，怎么看，看什么是摆在面前的问题。

其实对于产品经理而言，我们应该更关注这个公司可以提供什么样的API接口服务，比如我知道高德可以提供地图API，规划路线的API，这样的话在我们设计功能和工作中就可以想到调用他们的服务或者参考。

所以产品小白们看不懂也不用过于担心，未来工作中你也会更深入了解清楚，因为看懂并不复杂，以下是API接口的核心点，所有的说明文档离不开这5个核心点。

以下说明均以微信开放平台为例说明，文末有各开放平台的地址，大家有空可以去学习。好了，事不宜迟，现在我们来建立一个场景。

我们现在有一个APP，需要用户在购买的时候调起微信支付的API，完成购买。请各位自动进入这个场景，把自己当作一位产品经理。

1. 接口地址

现在Now，用户点击付款，我们需要告诉微信，我们要调起你们的收银台啦接口文档设计！但，去哪里告诉呢？这就需要接口地址了，也就相当于向微信的这条链接传输指定的数据。

一个链接地址不是我们理解的一个页面，你可以理解是一个电话号码，小白们要改变这个观念。

此时我们可以看到接口文档告诉我们链接是如下这条，那我们现在已经拨通微信的电话了。

2. 请求参数（报文）

我们现在需要告诉微信，你想调用收银台对吧。那我们需要写下来，此时生成的叫做报文，也就是你想告诉这个接口的内容是什么？相当于前文函数的输入x=2。

一般来说，报文的格式和内容都是按接口文档规定的。如下文就是微信开放平台对调起收银台的报文要求。

我们先来看前2个参数，你现在跟微信在对话，是不是应该先告诉微信，你是谁？这里微信的文档告诉你应该要用应用ID+商户号来确定你的身份，什么意思呢？

比如你是A商户，下面有a，b，c三个APP，所以微信要知道你是哪个商家，下面的哪个APP要用收银台。这是非常重要的，微信后面要把收到的钱打到对应的账户以及统计数据等。

那我们就在报文里面写下这两句话：

<appidwx2421b1c4370ec43b</appid（我的应用ID是wx2421…….）

<mch_id10000100</mch_id（我的商户号是10000…….）

好了，现在微信知道你是谁了，那你要告诉微信，你需要微信支付帮你收多少钱对吧？这里定义了货币类型和总金额，也就是收什么货币，收多少钱。

这里你看，货币类型的必填写了否，也就是说你也可以不告诉微信支付货币类型是什么，因为他在后面备注了默认是人民币。

好的，那我们写下两段报文

<free_typeCNY</ free_type （我要收人民币）

<total_fee1</total_fee（我要收1元）

好了，现在微信知道你是谁，也知道要收多少钱了，那接下来微信支付要把收钱结果告诉你呀，因为你得知道用户是成功支付了才能继续发货，服务啊等等的。所以这里我们用到通知地址，就是告诉微信，等下完事了他去哪里告诉你支付结果。那我们把地址写好：

<notify_urlhttp://wxpay.wxutil.com/pub_v2/pay/notify.v2.php</notify_url

3. 返回结果

刚刚微信支付已经去收款了，现在他要在我们留下的通知地址中，告诉我们结果了。结果无非是两种：成功收款？收款不成功？

（1）成功

很顺利，现在用户成功付钱了，并且微信也把成功的消息告诉我们了，并且他还把用户支付的一些信息也告诉我们。

那这里就是微信支付成功收款后告诉我们的信息。

应用APPID，商户号：告诉你我成功扣款的是哪家商户的哪个APPID的交易。

业务结果：成功或失败

（2）失败

在产品设计的时候，我们往往很关注失败的情况，当收款失败的时候，微信同时会告诉你失败的原因，如下图很好理解，失败的原因有很多很多种，我们在设计的时候往往要分析每种失败的原因，为每个失败的原因设计页面和用户提示，以确保用户能理解。

以上就是API接口基本运作模式的理解，下面我将继续更新API接口的一些更为深入和细节的关键元素，如请求方式/签名/加解密等等。

可供参考的开放平台网站

微信支付：https://pay.weixin.qq.com/wiki/doc/api/index.html

高德平台开放平台：https://lbs.amap.com/

Restful接口文档规范

基于目前的大前端时代，对于常年负责后台开发的我来说， 最重要的就是提供稳定的接口和文档。便于小伙伴们进行业务对接。

当下常用的是RestFul风格的定义规范， 之前开发是清一色Get、Post。引入RestFul后感觉接口定义规范很多，看接口地址就知晓是什么功能， 一起来看看列的一些基础规范吧。
API与客户端用户的通信协议，总是使用HTTPS协议，以确保交互数据的传输安全。
应该尽量将API部署在专用域名之下： https://api.example.com

如果确定API很简单,不会有进一步扩展,可以考虑放在主域名下： https://www.example.com/api
https://api.example.com/v{n}

1、应该将API的版本号放入URL。

2、采用多版本并存，增量发布的方式。

3、n代表版本号，分为整型和浮点型

整型： 大功能版本， 如v1、v2、v3 ...

浮点型： 补充功能版本， 如v1.1、v1.2、v2.1、v2.2 ...

4、对于一个 API 或服务，应在生产中最多保留 3 个最详细的版本
路径又称"终点"（end point），表示API的具体网址。

1、在RESTful架构中，每个网址代表一种资源(resource),所以网址中不能有动词，只能有名词。

【所用的名词往往与数据库的表格名对应】

2、数据库中的表一般都是同种记录的"集合"(collection),所以API中的名词也应该使用复数。

例子: https://api.example.com/v1/products

https://api.example.com/v1/users

https://api.example.com/v1/employees
GET（SELECT）： 从服务器取出资源（一项或多项）。

POST（CREATE）： 在服务器新建一个资源。

PUT（UPDATE）： 在服务器更新资源（客户端提供改变后的完整资源）。

DELETE（DELETE）： 从服务器删除资源。

例子：

GET /v1/products 获取所有商品

GET /v1/products/ID 获取某个指定商品的信息

POST /v1/products 新建一个商品

PUT /v1/products/ID 更新某个指定商品的信息

DELETE /v1/products/ID 删除某个商品,更合理的设计详见【9、非RESTful API的需求】

GET /v1/products/ID/purchases 列出某个指定商品的所有投资者

GET /v1/products/ID/purchases/ID 获取某个指定商品的指定投资者信息
若记录数量很多，服务器不可能返回全部记录给用户。

API应该提供分页参数及其它筛选参数，过滤返回结果。

/v1/products?page=1pageSize=20 指定第几页，以及每页的记录数。

/v1/products?sortBy=nameℴ=asc 指定返回结果按照哪个属性排序，以及排序顺序。
传入参数分为4种类型：

1、cookie： 一般用于OAuth认证

2、request header： 一般用于OAuth认证

3、请求body数据：

4、地址栏参数：

1）restful 地址栏参数 /v1/products/ID ID为产品编号，获取产品编号为ID的信息

2）get方式的查询字段 见【六、过滤信息】
response：

----------------------------------------

{

status: 200, // 详见【status】

data: {

code: 1, // 详见【code】

data: {} || [], // 数据

message: '成功', // 存放响应信息提示,显示给客户端用户【须语义化中文提示】

sysMessage: 'success' // 存放响应信息提示,调试使用,中英文都行

... // 其它参数，如 total【总记录数】等

},

msg: '成功', // 存放响应信息提示,显示给客户端用户【须语义化中文提示】

sysMsg: 'success' // 存放响应信息提示,调试使用,中英文都行

}

----------------------------------------

【status】:

200: OK 400: Bad Request 500：Internal Server Error

401：Unauthorized

403：Forbidden

404：Not Found

【code】:

1: 获取数据成功 | 操作成功 0：获取数据失败 | 操作失败
1、实际业务开展过程中，可能会出现各种的api不是简单的restful 规范能实现的。

2、需要有一些api突破restful规范原则。

3、特别是移动互联网的api设计，更需要有一些特定的api来优化数据请求的交互。

1)、删除单个 | 批量删除 ： DELETE /v1/product body参数{ids：[]}

2)、页面级API : 把当前页面中需要用到的所有数据通过一个接口一次性返回全部数据
1、前端需要哪些字段，API接口应该返回哪些字段，字段不多也不少。

2、更新功能尽量做到：初次返回的原始数据参数与提交更新的数据参数结构一致。

3、时间参数，尽量以一致格式的字符串传递， 如：

‘2019-01’ | ‘2019/01’

‘2019-01-01’ | ‘2019/01/01’

‘2019-01-01 12:12:12’ | ‘2019/01/01 12:12:12’
1、尽量采用自动化接口文档，可以做到在线测试，同步更新。

2、应包含：接口BASE地址、接口版本、接口模块分类等。

3、每个接口应包含：

接口地址：不包含接口BASE地址。

请求方式: get、post、put、delete等。

请求参数：数据格式【默认JSON、可选form data】、数据类型、是否必填、中文描述。

相应参数：类型、中文描述。

软件接口说明文档怎么写

1 引言
1．1编写目的
说明编写这份详细设计说明书的目的，指出预期的读者。
1．2背景
说明：
a．待开发软件系统的名称；
b．本项目的任务提出者、开发者、用户和运行该程序系统的计算中心。
1．3定义
列出本文件中用到专门术语的定义和外文首字母组词的原词组。
1．4参考资料
列出有关的参考资料，如：
a．本项目的经核准的计划任务书或合同、上级机关的批文；
b．属于本项目的其他已发表的文件；
c．本文件中各处引用到的文件资料，包括所要用到的软件开发标准。 列出这些文件的标题、文件编号、发表日期和出版单位，说明能够取得这些文件的来源。
2 程序系统的结构
用一系列图表列出本程序系统内的每个程序（包括每个模块和子程序）的名称、标识符和它们之间 的层次结构关系。
3 程序1（标识符）设计说明
从本章开始，逐个地给出各个层次中的每个程序的设计考虑。以下给出的提纲是针对一般情况的。 对于一个具体的模块，尤其是层次比较低的模块或子程序，其很多条目的内容往往与它所隶属的上一层 模块的对应条目的内容相同，在这种情况下，只要简单地说明这一点即可。
3．1程序描述
给出对该程序的简要描述，主要说明安排设计本程序的目的意义，并且，还要说明本程序的特点（如 是常驻内存还是非常驻？是否子程序？是可重人的还是不可重人的？有无覆盖要求？是顺序处理还是并发 处理卜…．．等）。
3．2功能
说明该程序应具有的功能，可采用IPO图（即输入一处理一输出图）的形式。
3．3性能
说明对该程序的全部性能要求，包括对精度、灵活性和时间特性的要求。
3．4输人项
给出对每一个输入项的特性，包括名称、标识、数据的类型和格式、数据值的有效范围、输入的方式。 数量和频度、输入媒体、输入数据的来源和安全保密条件等等。
3． 5输出项
给出对每一个输出项的特性，包括名称、标识、数据的类型和格式，数据值的有效范围，输出的形式、 数量和频度，输出媒体、对输出图形及符号的说明、安全保密条件等等。
3．6算法
详细说明本程序所选用的算法，具体的计算公式和计算步骤。
3．7流程逻辑
用图表（例如流程图、判定表等）辅以必要的说明来表示本程序的逻辑流程。
3．8接口
用图的形式说明本程序所隶属的上一层模块及隶属于本程序的下一层模块、子程序，说明参数赋值和调用方式，说明与本程序相直接关联的数据结构（数据库、数据文卷）。
3．9存储分配
根据需要，说明本程序的存储分配。
3．10注释设计
说明准备在本程序中安排的注释，如：
a． 加在模块首部的注释；
b．加在各分枝点处的注释； 对各变量的功能、范围、缺省条件等所加的注释；
d．对使用的逻辑所加的注释等等。
3．11限制条件
说明本程序运行中所受到的限制条件。
3．12测试计划
说明对本程序进行单体测试的计划，包括对测试的技术要求、输入数据、预期结果、进度安排、人员职责、设备条件驱动程序及桩模块等的规定。
3．13尚未解决的问题
说明在本程序的设计中尚未解决而设计者认为在软件完成之前应解决的问题。
4 程序2（标识符）设计说明
用类似3的方式，说明第2个程序乃至第N个程序的设计考虑。 关于接口文档设计和接口文档设计教程的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 接口文档设计的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于接口文档设计教程、接口文档设计的信息别忘了在本站进行查找喔。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。