知识分享之规范——RESTful API规范 背景 知识分享之规范类别是我进行整理的日常开发使用的各类规范说明,作为一个程序员需要天天和各种各样的规范打交道,而有些规范可能我们并不是特别了解,为此我将一些常见的规范均整理到知识分享之规范系列中...符合 REST 架构风格的 Web API(或 Web 服务)是 REST API。...标准 image.png 1.统一接口 一旦开发人员熟悉了您的一个 API,他应该能够对其他 API 遵循类似的方法。...日常我们进行各种各样的增删改查,规范中推荐如下HTTP请求方式进行提供相关接口: GET 查询、POST创建、PUT更新、DELETE删除、 REST API 使用HTTP 响应消息的状态行部分来通知客户端其请求的总体结果...4xx:客户端错误——这类错误状态代码将矛头指向客户端。 5xx:服务器错误——服务器对这些错误状态代码负责。
RESTful API接口规范是设计Web服务的一种方法,它基于HTTP协议,并通过一系列约定来组织接口。...以下是RESTful API接口规范的主要组成部分:协议 :使用HTTPS协议进行通信,确保数据传输的安全性。域名 :API部署在专用的子域名下,如https://api.example.com。...错误处理 :返回合适的HTTP状态码和错误信息,如404表示资源不存在,500表示服务器错误。安全机制 :使用HTTPS进行数据传输。可能需要使用Token进行身份验证。...遵循这些规范可以确保API的可用性、可扩展性和安全性,同时使得API易于理解和使用。
RESTful 是目前最流行的 API 设计规范,用于 Web 数据接口的设计 http请求方法 RESTful API 设计规范 关于「能愿动词」的使用 为了避免歧义,文档大量使用了「能愿动词」,对应的解释如下...如果你的应用很庞大或者你预计它将会变的很庞大,那 应该 将 API 放到子域下(api.example.com)。...你 必须 在引入新版本 API 的同时确保旧版本 API 仍然可用。...50x 服务器错误 500 Internal Server Error 503 Service Unavailable 数据响应格式 错误格式 对于错误数据,默认使用如下结构: 'message' =>...':message', // 错误的具体描述 'errors' => ':errors', // 参数的具体错误描述,422 等状态提供 'code' => '
除了https的协议之外,能不能加上通用的一套算法以及规范来保证传输的安全性呢?...下面我们就来讨论下常用的一些API设计的安全方法,可能不一定是最好的,有更牛逼的实现方式,但是这篇是我自己的经验分享....如果正确生成一个token保存到redis中,如果错误返回错误信息 AccessToken accessToken = this.saveToken(0, appInfo, null);...ApiCodeEnum /** * 错误码code可以使用纯数字,使用不同区间标识一类错误,也可以使用纯字符,也可以使用前缀+编号 * * 错误码:ERR + 编号 * * 可以使用日志级别的前缀作为错误类型区分...Info(I) Error(E) Warning(W) * * 或者以业务模块 + 错误号 * * TODO 错误码设计 * * Alipay 用了两个code,两个msg(https:/
概述 这篇文章分享 API 接口设计规范,目的是提供给研发人员做参考。 规范是死的,人是活的,希望自己定的规范,不要被打脸。...platform 平台 iOS、Android system 系统 ios 13.3、android 9 device 设备型号 iPhone XR、小米9 udid 设备唯一标示 apiVersion API...安全规范 敏感参数加密处理 登录密码、支付密码,需加密后传输,建议使用 非对称加密。 其他规范 参数命名规范 建议使用驼峰命名,首字母小写。 requestId 建议携带唯一标示追踪问题。...返回参数 参数 类型 说明 备注 code Number 结果码 成功=1失败=-1未登录=401无权限=403 showMsg String 显示信息 系统繁忙,稍后重试 errorMsg String 错误信息...暂时就想到这么多,规范这东西不是一成不变的,发现有不妥的及时调整吧。 你们接口的输入输出 Key,命名是用驼峰还是下划线?欢迎留言。
接口,实现对这张图片的删除操作,这个api应该怎么设计?...除了HTTP METHOD,rest另外一套重要的规范就是HTTP STATUS,这套状态码规范定义了常规的api操作所可能产生的各种可能结果的描述,遵循这套规范,会使得你的api变得更加可读,同时也便于各种网络...401 Unauthorized - [*]:表示用户没有权限(令牌、用户名、密码错误)。 403 Forbidden - [*] 表示用户得到授权(与401错误相对),但是访问是被禁止的。...422 Unprocesable entity - [POST/PUT/PATCH] 当创建一个对象时,发生一个验证错误。...500 INTERNAL SERVER ERROR - [*]:服务器发生错误,用户将无法判断发出的请求是否成功。 最后推荐大家github的api文档: ? 完毕!!!
作者:马一特 cnblogs.com/mayite/p/9798913.html RESTful 是目前最流行的 API 设计规范,用于 Web 数据接口的设计。...客户端发出的数据+操作指令都是“动词+宾语”的结构,比如GET /articles这个命令,GET是动词,/articles是宾语,动词通常就有5种HTTP请求方法,对应CRUD操作,根据 HTTP 规范...HTTP/1.1 303 See Other Location: /api/orders/12345 4xx 状态码 4xx状态码表示客户端错误,主要有下面几种。...5xx 状态码 5xx状态码表示服务端错误。一般来说,API 不会向用户透露服务器的详细信息,所以只要两个状态码就够了。...正确的做法是,状态码反映发生的错误,具体的错误信息放在数据体里面返回。下面是一个例子。
API接口测试规范总结 目录 1、参数校验 2、返回值校验 3、命名规范 4、业务判断 5、安全校验 1、参数校验 1、正常场景 (1)功能按照接口规范要求实现 (2)返回状态码200 2、异常场景...(1)参数为空 直接为空 null [] {} (2)参数错误 (3)无操作权限 (4)特定的业务逻辑报错,涉及敏感的报错不应该有明确的原因,例如登录失败就不能报成密码错误或手机号码错误 (5)...,参数类型非法,例:int传string 必填参数数值范围错误,数值越界 必填参数为空格,前面,中间,尾部 (3)必填参数不传,必填参数全部为空,必填参数部分为空 (4)必填参数组合,有些参数需要配合一起使用时需组合测试...4、非必填参数 (1)接口文档规范要求非必传的参数 (2)正向,所有参数均传正确 (3)逆向 某个参数为空,需要做判空处理 非必填参数少传一个,接收方需要处理 5、升级接口 (1)什么情况下需要升级接口...老版本要兼容 2、返回值校验 1、返回数据是否必要 2、返回数据数量需要限制 案例: 电商下单接口测试环境返回2000多张优惠券 推荐服务挂掉,电商h5页面接口返回全部商品 3、契约验证 如上 3、命名规范
概要 BAAS 平台上的所有 API,必须严格遵守本规范。 通过本文档规范 BAAS 平台所有向外提供 API,体现技术的统一性、规范性。...API 设计规范 2.1....· 500:内部程序错误。 其中,201、404这两个状态码,是需要API开发者在每一个API中,根据业务逻辑的执行结果来主动返回的。其它的状态码由框架统一进行返回。 2....如:01表示ACS,那么010001可能表示ACS模块中的登录API的用户名错误、010002表示ACS中的登录API的用户密码错误。 2.2.5....其中 message 表示错误的信息。方便进行调试。
但是也有意外情况,如果是在一个需要return的函数中去使用switch,那么此时return会直接跳出当前进程,出现意料之外的情况,所以和大家约定,不管什么情况下,都使用配套的关键字break,此外,在严格规范下
4、下面的奇怪的写法 如果当前if判断下没有要处理的事情那么请直接去掉 5、逗号及分号的不严谨 此处没有什么说明,这应该是写代码时候粗心导致,请避免这样粗心大意带来的错误异常,要求每一句结束请用分号结束
本文作者:IMWeb 梁伟盛 原文出处:IMWeb社区 未经同意,禁止转载 RESTful API 规范 v1.0 [toc] URI URI规范 不要用大写 单词间使用下划线'_' 不使用动词...我们使用此方案) 自定义Media-Type参考资料github ---- 状态码 成功 Code Method Describe 200 ALL 请求成功并返回实体资源 201 POST 创建资源成功 客户端错误...Code Method Describe 400 ALL 一般是参数错误 401 ALL 一般用户验证失败(用户名、密码错误等) 403 ALL 一般用户权限校验失败 404 ALL 资源不存在(github...在权限校验失败的情况下也会返回404,为了防止一些私有接口泄露出去) 422 ALL 一般是必要字段缺失或参数格式化问题 服务器错误 CODE METHOD DESCRIBE 500 ALL 服务器未知错误
在日常开发中,一个优雅的API,必须提供简单明了的响应值,然后根据状态码就可以大概知道问题的所在。这里主要整理一下HTTP状态码和自定义状态码。...2、HTTP状态码分类 HTTP状态码可以分为5类:消息响应、成功响应、重定向、客户端错误、服务器错误。 状态 描述 100 继续。客户端应继续其请求 101 切换协议。...3、自定义响应状态码规范 后端返回给前端一般使用json格式,定义如下: { #返回状态码 Code:integer, #返回信息描述 message:string,..."), //用户错误:2001~2999 USER_LOGIN_ERROR(2001, "账号不存在或密码错误"), USER_ACCOUNT_FORBIDDEN(2002, "...return new Result(resultStatus, data); } } 3.4、返回体测试 @RestController @RequestMapping("/api
注:RESTful API是目前比较成熟的一套Web应用程序的API设计理论,本文不对RESTful API过多介绍。...其他容易产生错误的例子如:0和”0″等。 结构数据类型 Object(对象)是无序的集合,以键值对的方式保持数据。一个Object中包含零到多个name/value的数据,数据间以逗号(,)分隔。...URL规范 URL代表所提供的API的唯一性和永久性,在此之前我们应该[SHOULD]设计合理的URL: 必须[MUST]全部使用小写字母拼写URL // good http://www.example.com...返回错误的状态码可能导致错误不被响应,数据不被处理。 参考:List_of_HTTP_status_codes Content-Type Content-Type字段定义了响应体的类型。...状态码的定义也最好有一套规范,如按照用户相关、授权相关、各种业务,做简单的分类: // 授权相关 1001: 无权限访问 1002: access_token过期 1003: unique_token无效
接口签名 接口签名是一种常见的安全措施,用于确保API请求的完整性和身份验证。...错误处理:如果签名验证失败,服务器应该返回一个错误响应,并记录可能的安全事件。接口签名机制能够有效地防止API请求被篡改,确保数据的安全性和请求的合法性。...格式建议 以下是一些建议,用于确保API响应格式的统一性: 明确的版本号:在响应中包含API版本号,这样在API更新时可以保持向后兼容性。...统一的状态码:使用标准HTTP状态码来表示请求的结果,如200表示成功,400表示客户端错误,500表示服务器错误等。...通过以上措施,可以确保API接口的响应格式统一、清晰,并且易于客户端开发者使用和集成。
本文总结了 RESTful API 设计相关的一些原则,只覆盖了常见的场景。有些规则只是针对自己项目而言,并非其他做法都是错误的。 1....URI规范 不用大写; 用中杠-而不用下杠_; 参数列表要encode; URI中的名词表示资源集合,使用复数形式; 资源集合与单个资源 资源集合: /zoos //所有动物园 /zoos...错误处理 不要发生了错误但给2xx响应,客户端可能会缓存成功的http请求; 正确设置http状态码,不要自定义; Response body 提供 1) 错误的代码(日志/问题追查);2) 错误的描述文本...对第三点的实现稍微多说一点: Java 服务器端一般用异常表示 RESTful API 的错误。API 可能抛出两类异常:业务异常和非业务异常。...URI失效 随着系统发展,总有一些API失效或者迁移,对失效的API,返回404 not found 或 410 gone;对迁移的API,返回 301 重定向。
本文作者:IMWeb 梁伟盛 原文出处:IMWeb社区 未经同意,禁止转载 RESTful API 规范 v1.0 [toc] URI URI规范 不要用大写 单词间使用下划线'_' 不使用动词...我们使用此方案) 自定义Media-Type参考资料github 状态码 成功 Code Method Describe 200 ALL 请求成功并返回实体资源 201 POST 创建资源成功 客户端错误...Code Method Describe 400 ALL 一般是参数错误 401 ALL 一般用户验证失败(用户名、密码错误等) 403 ALL 一般用户权限校验失败 404 ALL 资源不存在(github...在权限校验失败的情况下也会返回404,为了防止一些私有接口泄露出去) 422 ALL 一般是必要字段缺失或参数格式化问题 服务器错误 CODE METHOD DESCRIBE 500 ALL 服务器未知错误
RESTful是目前比较流行的接口路径设计规范,基于HTTP,一般使用JSON方式定义,通过不同HttpMethod来定义对应接口的资源动作,如:新增(POST)、删除(DELETE)、更新(PUT、PATCH...路径设计 在RESTful设计规范内,每一个接口被认为是一个资源请求,下面我们针对每一种资源类型来看下API路径设计。...针对不同的状态码我们要做出不同的反馈,下面我们先来看一个常见的参数异常错误响应设计方式: # 发起请求 curl -X POST -H 'Content-Type: application/json'...{ "code": "400", "message": "用户名必填." } 在服务端我们可以控制不同状态码、不同异常的固定返回格式,不应该将所有的异常请求都返回200,然后对应返回错误...timestamp 请求响应的时间戳 总结 RESTful是API的设计规范,并不是所有的接口都应该遵循这一套规范来设计,不过我们在设计初期更应该规范性,这样我们在后期阅读代码时根据路径以及请求方式就可以了解接口的主要完成的工作
,需要自行设计一套规范,那就意味着,需要对 Open API 进行一些规范约束了,遂有此文。...Open API 和前端页面一样,一直都是产品的门面, Open API 不规范,会拉低产品的专业性。...本文将围绕诸多因素,尝试探讨出一份合适的 Open API 开放规范。 Open API 设计考虑因素 一个完善的 Open API 规范到底应该规范哪些东西?...站在设计角度,需要考虑:命名规范,构成规范,路径规范,出入参规范,数据类型规范,统一返回值规范,错误码规范,分页规范。...尽管规范是无罪的,但在 ROA 风格在实践过程中,我还是见识过不少“坑”的: 要求资源先行,即先设计资源,后设计接口,对软件开发流程要求较高 错误的 ROA 设计案例 1:tomcat 等应用服务器在处理
Object object = null; String string = object.toString(); 上面的代码就会出现空指针的错误。...在对象初始化的时候给他一个默认值或者是默认构造实现 User user = new User(); String name = StringUtils.EMPTY; 3.返回空集合 在返回一个集合的话,默认是null,统一规范返回一个空集合