WebAPI接口开发实践
2021-01-14 17:11
标签:效果 表示 现在 一个 com 属性 produces rev pre 在团队两年多陆续负责了几个项目的开发上线已经代码的review,特别是对老项目的重构过程中,发现之前的API设计是没有任何规范和约定的,不同的开发同学有不同的习惯,因此需要一套规范去约定,现在分享一下我们目前试运行的一套规范,一起交流完善下。 第三步找对应API对接人,确认接口是否符合要求 这三步其实是个闭环,只有等到全部通过后才会正式开始开发API 接口命名遵循像个原则: 禁止把所有数据库字段全部返回,统一使用Dto,只返回调用方需要的字段 根据 HTTP 标准,HTTP 请求可以使用多种请求方法。 GET(SELECT): 从服务器获取单个资源或者资源列表 x-[应用英文缩写]-[语义化英文单词说明用途] 示例: 全部统一使用 整体效果 注释效果 Swashbuckle 和 ASP.NET Core 入门 WebAPI接口开发实践 标签:效果 表示 现在 一个 com 属性 produces rev pre 原文地址:https://www.cnblogs.com/sagecheng/p/12250774.html背景
WebAPI开发流程
命名规范
/
简单
易懂
出入参规范
-
HTTP 请求方法使用规范
HTTP1.0 定义了三种请求方法: GET, POST 和 HEAD方法。
HTTP1.1 新增了六种请求方法:OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法。
这里统一只是用 GET, POST,PUT,DELETE,PATCH
POST(CREATE):发送请求创建一个新的资源
PUT(UPDATE):通过接口更新服务器上的资源信息,资源内容全量更新,提供资源全部字段信息
DELETE(DELETE):通过删除服务器上的资源
PATCH(UPDATE) :通过接口更新服务器上的资源信息,资源内容增量更新,仅提供更新的属性信息
具体使用规范,使用GET查询获取信息,POST创建新的资源,PUT修改已存在资源信息,DELETE删除服务器资源信息,不强制要求使用Patch。HTTP码状态使用规范
自定义Header规范,
X-Test-Authorization: qwaszxerdfcvtyghbn返回规范
Content-Type = application/json
格式返回请求失败的Response
success
true
data
返回,无返回值时为{}
,禁止使用null
返回X-[项目英文缩写]-ResponseId
{
"isSuccess": true,
"code": 200,
"message": "success",
"data": {
"id": 0,
"value": "Default"
},
"timestamp": "02/02/2020 13:19:22"
}
请求异常的Response
false
data
统一返回为{}
X-[项目英文缩写]-ResponseId
{
"isSuccess": false,
"code": 400,
"message": "Bad Request",
"value": {},
"timestamp": "02/02/2020 13:35:33"
}
接口注释说明
约定
///
///
///
/// Swagger相关效果
参考文章