后端api规范说明文档

我们此次后端api的实现主要是按照RESTful api规范来设计的,就是符合REST架构下设计api的规范。简单的来说REST结构就是:利用URL定位资源,用HTTP动词(GET,POST,PUT,DELETE)来描述相应操作。

RESTful api主要的意义在于它可以让在不同形式的前端所接受到的用户请求能够统一的发送到一个后台并返回不同的前端。RESTful api是由后端SERVER实现并提供给前端来调用的一个接口。前端调用API来向后台发起HTTP请求,后台响应请求并将处理结构反馈给前端。所以说RESTful是典型的基于HTTP的协议。所以下面我们对RESTful api的设计原则与规范进行相应的说明:

https://blog.csdn.net/qq_31805915/article/details/79951929

一、协议

API与用户的通信协议,总是使用HTTPs协议。

二、域名

尽量将API部署在专用域名之下:

例如https://api.jupiter.com

三、版本

将我们API的版本号放入URL中:

例如https://api.jupiter.com/v1/

四、路径

路径又称"终点"(endpoint),表示API的具体网址。

在RESTful架构中,每个网址代表一种资源(resource),所以网址中不能有动词,只能有名词,而且所用的名词往往与数据库的表格名对应。一般来说,数据库中的表都是同种记录的"集合"(collection),所以API中的名词也应该使用复数。

举例来说,有一个API提供动物园(zoo)的信息,还包括各种动物和雇员的信息,则它的路径应该设计成下面这样:

https://api.jupiter.com/zoo

https://api.jupiter.com/animals

https://api.jupiter.com/employees

五、HTTP动词

对于资源的具体操作类型,由HTTP动词来表示,常用的HTTP动词有下面五个(括号中对应的是相应的SQL命令):

GET(SELECT):从服务器取出资源(一项或多项)。

POST(CREATE):在服务器新建一个资源。

PUT(UPDATE):在服务器更新资源(客户端提供改变后的完整资源)。

PATCH(UPDATE):在服务器更新资源(客户端提供改变的属性)。

DELETE(DELETE):从服务器删除资源。

下面是一些简单的例子:

GET /zoos:列出所有动物园

POST /zoos:新建一个动物园

GET /zoos/ID:获取某个指定动物园的信息

PUT /zoos/ID:更新某个指定动物园的信息(提供该动物园的全部信息)

PATCH /zoos/ID:更新某个指定动物园的信息(提供该动物园的部分信息)

DELETE /zoos/ID:删除某个动物园

GET /zoos/ID/animals:列出某个指定动物园的所有动物

DELETE /zoos/ID/animals/ID:删除某个指定动物园的指定动物

六、过滤信息

如果记录数量很多,服务器不可能都将它们返回给用户。API应该提供参数,过滤返回结果,下面是一些常见的参数:

?limit=10:指定返回记录的数量

?offset=10:指定返回记录的开始位置。

?page=2&per_page=100:指定第几页,以及每页的记录数。

?sortby=name&order=asc:指定返回结果按照哪个属性排序,以及排序顺序。

?animal_type_id=1:指定筛选条件

参数的设计允许存在冗余,即允许API路径和URL参数偶尔有重复。比如,GET /zoo/ID/animals 与 GET /animals?zoo_id=ID 的含义是相同的。

七、状态码

服务器向用户返回的状态码和提示信息,常见的有以下一些(方括号中是该状态码对应的HTTP动词):

200 OK - [GET]:服务器成功返回用户请求的数据,该操作是幂等的(Idempotent)。

201 CREATED - [POST/PUT/PATCH]:用户新建或修改数据成功。

202 Accepted - [*]:表示一个请求已经进入后台排队(异步任务)

204 NO CONTENT - [DELETE]:用户删除数据成功。

400 INVALID REQUEST - [POST/PUT/PATCH]:用户发出的请求有错误,服务器没有进行新建或修改数据的操作,该操作是幂等的。

401 Unauthorized - [*]:表示用户没有权限(令牌、用户名、密码错误)。

403 Forbidden - [*] 表示用户得到授权(与401错误相对),但是访问是被禁止的。

404 NOT FOUND - [*]:用户发出的请求针对的是不存在的记录,服务器没有进行操作,该操作是幂等的。

406 Not Acceptable - [GET]:用户请求的格式不可得(比如用户请求JSON格式,但是只有XML格式)。

410 Gone -[GET]:用户请求的资源被永久删除,且不会再得到的。

422 Unprocesable entity - [POST/PUT/PATCH] 当创建一个对象时,发生一个验证错误。

500 INTERNAL SERVER ERROR - [*]:服务器发生错误,用户将无法判断发出的请求是否成功。

详细的状态码列表可见这里

八、错误处理

如果状态码是4xx,就应该向用户返回出错信息。一般来说,返回的信息中将error作为键名,出错信息作为键值即可。

例如:

  1. {

  2.  

    error: "Invalid API key"

  3.  

    }

九、返回结果

针对不同操作,服务器向用户返回的结果应该符合以下规范:

GET /collection:返回资源对象的列表(数组)

GET /collection/resource:返回单个资源对象

POST /collection:返回新生成的资源对象

PUT /collection/resource:返回完整的资源对象

PATCH /collection/resource:返回完整的资源对象

DELETE /collection/resource:返回一个空文档

原文地址:https://www.cnblogs.com/du-jun/p/10772925.html

时间: 2024-08-03 15:07:08

后端api规范说明文档的相关文章

Java Servlet API中文说明文档

Java Servlet API中文说明文档译者前言:       近来在整理有关Servlet资料时发现,在网上竟然找不到一份中文的Java Servlet API的说明文档,而在有一本有关JSP的书后面附的Java Servlet API说明竟然不全,而这份文档的2.1a版在1998年的11月份就已定稿.所以我决定翻译一份中文的文档(其中一些与技术关系不大的部分已被略去),有兴趣的读者可以从http: //java.sun.com/products/servlet/2.1/servletsp

.NET Core WebApi帮助文档使用Swagger生成Api说明文档

Swagger也称为Open API,Swagger从API文档中手动完成工作,并提供一系列用于生成,可视化和维护API文档的解决方案.简单的说就是一款让你更好的书写API文档的框架. 我们为什么选择swagger,现在的网站开发结果越来越注重前后端的分离,比如以前的webFrom到现在的mvc模式都是为了这个前后端的分离.就算再如何的分离实现,也是不可避免的要进行数据交互的,那么接口的重要性就提现出来了.他成了前端和后端交互的重要途径,API文档也因此成了前端开发人员与后端开发人员的重要纽带.

《暗黑世界V1.4》API说明文档

<暗黑世界V1.4>API说明文档 阵法位置示意图 上方:                        下方:      账号注册   100 请求信息 { username   str     用户名 password   str     密码 } 返回信息 { result     bool    指令调用是否成功 message    str     指令调用返回的信息 } 账号登陆   101 请求信息 { username   str     用户名 password   str 

app后端开发二:API接口文档工具

悲伤的历史 在进行app后端开发过程中,后端会提供出来很多的api接口供前端开发使用,为了让前端开发人员顺利使用,我们会写好一份文档,告诉他们这个接口你该用 GET 还是 POST 来访问,同时访问的时候该给我传递一些什么参数,以及正确的时候我会返回什么给你,已经返回的数据样式以及字段解释等等这些事情,我们都需要在文档中写好写清楚. 在 app后端开发一:基于swagger-ui构建api接口文档工具 这篇博客中,我写了 swagger-ui 的好处以及优势.但是在使用过程中,发现不够给力.我想

为ASP.NET WEB API生成人性化说明文档

一.为什么要生成说明文档 我们大家都知道,自己写的API要供他人调用,就需要用文字的方式将调用方法和注意事项等写成一个文档以更好的展示我们设计时的想法和思路,便于调用者更加高效的使用我们的API. 当然,您可以不借助任何工具,自己手工写文档,然后做成chm或者html的形式交给客户,就是效率有点低,并且在API更改后有需要手工更改说明文档. 那有没有一种既方便,又能在API发生改变时,自动更新说明文档呢?答案是肯定的. 二.自动生成说明文档的具体实现 我们这里主要是将GlobalConfigur

ASP.NET Core WebApi使用Swagger生成api说明文档看这篇就够了

引言 在使用asp.net core 进行api开发完成后,书写api说明文档对于程序员来说想必是件很痛苦的事情吧,但文档又必须写,而且文档的格式如果没有具体要求的话,最终完成的文档则完全取决于开发者的心情.或者详细点,或者简单点.那么有没有一种快速有效的方法来构建api说明文档呢?答案是肯定的, Swagger就是最受欢迎的REST APIs文档生成工具之一! 为什么使用Swagger作为REST APIs文档生成工具 Swagger 可以生成一个具有互动性的API控制台,开发者可以用来快速学

Swagger-UI 基于REST的API测试/文档类插件

现在多数的项目开发中,网站和移动端都需要进行数据交互和对接,这少不了使用REST编写API接口这种场景.例如我目前的工作,移动端交由了另一团队开发,不同开发小组之间就需要以规范和文档作为标准和协作基础.良好的文档可以让开发事半功倍,而作为又懒又要效率又能交代的码农,当然最希望一切自动化,或用小聪明来找到最适合的工具. Swagger-UI简单而一目了然.它能够纯碎的基于html+javascript实现,只要稍微整合一下便能成为方便的API在线测试工具.项目的设计架构中一直提倡使用TDD(测试驱

Java 如何将程序中的注释提取出来生成说明文档

第一种方法: 可以使用JavaDoc工具.它可以从程序源码中将类.方法.成员变量等文档注释抽取出来形成一个与源代码配套的API帮助文档.但是在编写代码时要以一定的规范做注释才可以.通过JavaDoc实现工具就可以同时生成代码的开发文档了.JavaDoc工具位于 C:\Program Files\Java\jdk1.6.0_10\bin 路径下. 其中/**...*/这种注释用于支持JavaDoc工具,还有一些以@开头的标识信息也可以抽取出来,如下图. 这里使用源码中StringBuffer.ja

Api接口文档管理工具,你知道哪些呢?

上周看到有人在我的Github开源项目中提了个issue,说是否考虑接入swagger.那今天我就用swagger与其他接口文档工具做对比,同时说说Api接口文档工具的那点事.如今,在前后端分离开发的这个年代,Api接口文档管理工具越来越显得重要.完整的Api接口文档能大大提升前后端开发协作的效率. image 目前市场有哪些比较优秀的接口文档管理工具呢?Swagger Api接口文档工具到底如何,我大致汇总一下吧! 一.Swagger 说到Swagger,他确实是为开发者发明的一款神器,他可以