API设计一

1 概述

针对目前项目中使用的前后端分离开发,越来越感觉到API设计的重要性,而不好的API设计通常让使用者通过URL无法明确知道这个URL到底是干什么用的,并且会显得设计混乱,在此将使用Restful风格设计API进行总结,并对在SpringBoot中具体实现Restful API的设计给出一定示例。

2 Restful API设计

使用Restful API是一种面向资源的设计风格,因此我们每一个URL对应的都是一个资源。从而针对资源的操作我们就可以使用HTTP的相应的请求方式来进行体现。

2.1 版本

应该将API的版本号放入URL中,例如http://localhost:8080/v1/

2.2 URL定义为名词

在之前我们通常看见/addUser、/editUser这样的URL定义,那么如果我们使用这样的定义就相当于我们放弃了HTTP请求方式(GET,POST,PUT,PATCH,DELETE)等的表达作用。并且我们也知道Restful提倡面向资源的URL路径,所以URL使用名词来进行定义,并且URL路径都是小写。例如:

操作用户资源:http://localhost:8080/v1/user

操作多个用户资源:http://localhost:8080/v1/users

操作财务部下的用户资源:http://localhost:8080/v1/accounting-department/user,从这里我们可以学到一点,针对某个资源需要两个单词来进行表达的时候我们可以使用“-”将两个单词连接起来。

2.3 使用HTTP请求方法来表达对资源的操作

上面我们知道了Restful API的URL定义是面向资源的,也就是每一个URL表示的是一种资源,那我我们要表达对资源的相关操作怎么办呢?而且Restful风格也强调了URL必须为名词构成。

这里我们就可以使用HTTP的请求方式来表达对资源的操作了。

GET:获取资源。

POST:创建资源。

PUT:修改资源。

PATCH:修改资源,这里的修改资源和PUT的区别在于这里只向后台传递了修改资源的部分内容,而PUT传递的是全部内容。

DELETE:删除资源。

还有两个不常用的HTTP动词。
HEAD:获取资源的元数据。
OPTIONS:获取信息,关于资源的哪些属性是客户端可以改变的。

2.4 数据传递格式

JSON阅读性更高,扩展性更强,适合各种环境和语言进行解析,现在大的互联网公司,对外提供的API基本都使用JSON。

2.5 使用HTTP状态码

针对请求的响应,我们可以直接利用Http的状态码来表达错误信息,这样也可以很形象地得知每次请求的结果,而不是每次请求都是200,然后再去响应体中获取是否有错误信息,这样响应体没有结果封装,没有额外的传输负担。

针对Http状态码无法表示的异常信息,我们可以增加自定义异常码。增加自定义头字段,Error-Message 表示错误信息,只在出现异常的时候返回。下面的表格内容参考自菜鸟教程。

HTTP状态码共分为5种类型:

分类 分类描述

  • 1** 信息,服务器收到请求,需要请求者继续执行操作
  • 2** 成功,操作被成功接收并处理
  • 3** 重定向,需要进一步的操作以完成请求
  • 4** 客户端错误,请求包含语法错误或无法完成请求
  • 5** 服务器错误,服务器在处理请求的过程中发生了错误

HTTP状态码列表:

状态码 状态码英文名称 中文描述

  • 100 Continue 继续。客户端应继续其请求

  • 101 Switching Protocols 切换协议。服务器根据客户端的请求切换协议。只能切换到更高级的协议,例如,切换到HTTP的新版本协议

  • 200 OK 请求成功。一般用于GET与POST请求

  • 201 Created 已创建。成功请求并创建了新的资源

  • 202 Accepted 已接受。已经接受请求,但未处理完成

  • 203 Non-Authoritative Information 非授权信息。请求成功。但返回的meta信息不在原始的服务器,而是一个副本

  • 204 No Content 无内容。服务器成功处理,但未返回内容。在未更新网页的情况下,可确保浏览器继续显示当前文档

  • 205 Reset Content 重置内容。服务器处理成功,用户终端(例如:浏览器)应重置文档视图。可通过此返回码清除浏览器的表单域

  • 206 Partial Content 部分内容。服务器成功处理了部分GET请求

  • 300 Multiple Choices 多种选择。请求的资源可包括多个位置,相应可返回一个资源特征与地址的列表用于用户终端(例如:浏览器)选择

  • 301 Moved Permanently 永久移动。请求的资源已被永久的移动到新URI,返回信息会包括新的URI,浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替

  • 302 Found 临时移动。与301类似。但资源只是临时被移动。客户端应继续使用原有URI

  • 303 See Other 查看其它地址。与301类似。使用GET和POST请求查看

  • 304 Not Modified 未修改。所请求的资源未修改,服务器返回此状态码时,不会返回任何资源。客户端通常会缓存访问过的资源,通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源

  • 305 Use Proxy 使用代理。所请求的资源必须通过代理访问

  • 306 Unused 已经被废弃的HTTP状态码

  • 307 Temporary Redirect 临时重定向。与302类似。使用GET请求重定向

  • 400 Bad Request 客户端请求的语法错误,服务器无法理解

  • 401 Unauthorized 请求要求用户的身份认证

  • 402 Payment Required 保留,将来使用

  • 403 Forbidden 服务器理解请求客户端的请求,但是拒绝执行此请求

  • 404 Not Found 服务器无法根据客户端的请求找到资源(网页)。通过此代码,网站设计人员可设置"您所请求的资源无法找到"的个性页面

  • 405 Method Not Allowed 客户端请求中的方法被禁止

  • 406 Not Acceptable 服务器无法根据客户端请求的内容特性完成请求

  • 407 Proxy Authentication Required 请求要求代理的身份认证,与401类似,但请求者应当使用代理进行授权

  • 408 Request Time-out 服务器等待客户端发送的请求时间过长,超时

  • 409 Conflict 服务器完成客户端的PUT请求是可能返回此代码,服务器处理请求时发生了冲突

  • 410 Gone 客户端请求的资源已经不存在。410不同于404,如果资源以前有现在被永久删除了可使用410代码,网站设计人员可通过301代码指定资源的新位置

  • 411 Length Required 服务器无法处理客户端发送的不带Content-Length的请求信息

  • 412 Precondition Failed 客户端请求信息的先决条件错误

  • 413 Request Entity Too Large 由于请求的实体过大,服务器无法处理,因此拒绝请求。为防止客户端的连续请求,服务器可能会关闭连接。如果只是服务器暂时无法处理,则会包含一个Retry-After的响应信息

  • 414 Request-URI Too Large 请求的URI过长(URI通常为网址),服务器无法处理

  • 415 Unsupported Media Type 服务器无法处理请求附带的媒体格式

  • 416 Requested range not satisfiable 客户端请求的范围无效

  • 417 Expectation Failed 服务器无法满足Expect的请求头信息

  • 500 Internal Server Error 服务器内部错误,无法完成请求

  • 501 Not Implemented 服务器不支持请求的功能,无法完成请求

  • 502 Bad Gateway 充当网关或代理的服务器,从远端服务器接收到了一个无效的请求

  • 503 Service Unavailable 由于超载或系统维护,服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的Retry-After头信息中

  • 504 Gateway Time-out 充当网关或代理的服务器,未及时从远端服务器获取请求

  • 505 HTTP Version not supported 服务器不支持请求的HTTP协议的版本,无法完成处理


作者:ONROAD0612
来源:CSDN
原文:https://blog.csdn.net/ONROAD0612/article/details/82216015
版权声明:本文为博主原创文章,转载请附上博文链接!

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 157,012评论 4 359
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 66,589评论 1 290
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 106,819评论 0 237
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 43,652评论 0 202
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 51,954评论 3 285
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,381评论 1 210
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,687评论 2 310
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,404评论 0 194
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,082评论 1 238
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,355评论 2 241
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 31,880评论 1 255
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,249评论 2 250
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 32,864评论 3 232
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,007评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,760评论 0 192
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 35,394评论 2 269
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,281评论 2 259

推荐阅读更多精彩内容

  • API定义规范 本规范设计基于如下使用场景: 请求频率不是非常高:如果产品的使用周期内请求频率非常高,建议使用双通...
    有涯逐无涯阅读 2,441评论 0 6
  • 一说到REST,我想大家的第一反应就是“啊,就是那种前后台通信方式。”但是在要求详细讲述它所提出的各个约束,以及如...
    时待吾阅读 3,339评论 0 19
  • 笔记 RESTful架构风格概述 RESTful架构风格 RESTful架构风格最初由Roy T. Fieldin...
    plutoese阅读 12,466评论 3 58
  • 天蓬被贬下凡尘,冷炙残羹睡安稳。 世人嘲讽浑不怕,喧嚣秽土保本真。
    羽佳成长故事阅读 128评论 0 0
  • 读之前可不曾想过这竟然是一本短篇小说。十篇小说,四篇自传,读起来倒是引人入胜,有些越读越精彩的感觉。书中到处...
    辫儿妈阅读 3,035评论 0 1