这篇 文章主要是借鉴他人,但是自己很想总结出一套规范,以供向我这样的新手使用,用来规范代码,如果有什么好的提议,请不吝赐教,本篇文章长期更新! 一.重要概念: REST,即Representational State Transfer的缩写.我对这个词组的翻译是"表现层状态转化". Resource(资源) :对象的单个实例. 例如,一只动物.它可以是一段文本.一张图片.一首歌曲.一种服务,总之就是一个具体的实在.你可以用一个URI(统一资源定位符)指向它,每种资源对应一个特定的URI…

1.RESTful发展背景及简介 网络应用程序,分为前端和后端两个部分.当前的发展趋势,就是前端设备层出不穷(手机.平板.桌面电脑.其他专用设备......).因此,必须有一种统一的机制,方便不同的前端设备与后端进行通信.这导致API构架的流行,甚至出现"APIFirst"的设计思想.RESTful API是目前比较成熟的一套互联网应用程序的API设计理论. REST(Representational State Transfer)表述性状态转换,REST指的是一组架构约束条件和原则.…

1.域名 1 应该尽量将API部署在专用域名之下. https://api.example.com 2 如果确定API很简单,不会有进一步扩展,可以考虑放在主域名下. https://example.org/api/ 2.版本(Versioning) 1 第一种将API的版本号放入URL. http://www.example.com/app/1.0/foo http://www.example.com/app/1.1/foo http://www.example.com/app/2.0/foo…

在设计接口时,有很多因素要考虑,如接口的业务定位,接口的安全性,接口的可扩展性.接口的稳定性.接口的跨域性.接口的协议规则.接口的路径规则.接口单一原则.接口过滤和接口组合等诸多因素,本篇文章将简要分析这些因素. 一 规范性建议 1.职责原则 在设计接口时,必须明确接口的职责,即接口类型,接口应解决什么业务问题等 2.单一性原则 在明确接口职责的条件下,尽量做到接口单一,即一个接口只做一件事,而非两件以上.很多非资深接口设计者,在设计接口时,总认为接口所做的事越多,越牛叉,这是非常严重的错误认识…

在设计接口时,有很多因素要考虑,如接口的业务定位,接口的安全性,接口的可扩展性.接口的稳定性.接口的跨域性.接口的协议规则.接口的路径规则.接口单一原则.接口过滤和接口组合等诸多因素,本篇文章将简要分析这些因素. 一 规范性建议 1.职责原则 在设计接口时,必须明确接口的职责,即接口类型,接口应解决什么业务问题等 2.单一性原则 在明确接口职责的条件下,尽量做到接口单一,即一个接口只做一件事,而非两件以上.很多非资深接口设计者,在设计接口时,总认为接口所做的事越多,越牛叉,这是非常严重的错误认识…

域名 应该尽量将API部署在专用域名之下. https://api.example.com 如果确定API很简单,不会有进一步扩展,可以考虑放在主域名下. https://www.example.org/api/ 版本(Versioning) 应该将API的版本号放入URL. http://www.example.com/app/1.0/foo http://www.example.com/app/1.1/foo http://www.example.com/app/2.0/foo 另一种做法是…

get 用来获取,post 用来新建(也可以用于更新),put 用来更新,delete 用来删除.…

1.注解 @Api:用在类上,说明该类的作用. @ApiOperation:注解来给API增加方法说明. @ApiImplicitParams : 用在方法上包含一组参数说明. @ApiImplicitParam:用来注解来给方法入参增加说明. @ApiResponses:用于表示一组响应 @ApiResponse:用在@ApiResponses中,一般用于表达一个错误的响应信息 l   code:数字,例如400 l   message:信息,例如"请求参数没填好" l   resp…

Restful API设计规范及实战   Restful API的概念在此就不费口舌了,博友们网上查哈定义文章很多,直入正题吧: 首先抛出一个问题:判断id为 用户下,名称为 使命召唤14(COD14) 的产品是否存在(话说我还是很喜欢玩类似二战的使命召唤这款额,题外话...)?如果这个问题出现在 MVC 项目中,我想我们一般会这样设计: api/products/isexist/{userId}/{productName} 我想你应该发现一些问题了,这种写法完全是 MVC 的方式,但并不适用于…

该仓库整理了目前比较流行的 RESTful api 设计规范,为了方便讨论规范带来的问题及争议,现把该文档托管于 Github,欢迎大家补充!! Table of Contents RESTful API 设计规范 关于「能愿动词」的使用 Protocol API Root URL Versioning 在 URL 中嵌入版本编号 通过媒体类型来指定版本信息 Endpoints HTTP 动词 Filtering Authentication Response 200 ok 201 Create…