RESTful API规范(详细版)

rest
是一种软件架构风格,如果你们的接口是 rest
接口,那么就可被认为你们的的接口是restful的,英文名词和形容词的区别。

rest
接口是围绕“资源”展开的,利用HTTP的协议,其实rest本也可以和HTTP无关,但是现在大家普遍的使用 rest
都是依托于HTTP协议。HTTP 的url即资源。

RFC 3986
定义了通用的URI语法:

URI = scheme “://” authority “/” path [ “?” query ][ “#” fragment ]
  • scheme: 指底层用的协议,如http、https、ftp
  • host: 服务器的IP地址或者域名
  • port: 端口,http中默认80
  • path: 访问资源的路径,就是咱们各种web 框架中定义的route路由
  • query: 为发送给服务器的参数
  • fragment: 锚点,定位到页面的资源,锚点为资源id

RESTful API设计

资源路径

对于rest资源的定义,即URL的定义,是最重要的;想要设计出优雅的、易读的rest 接口,其实还是听不容易的。

URL中不能有动词

在Restful架构中,每个网址代表的是一种资源,所以网址中不能有动词,只能有名词,动词由HTTP的 get、post、put、delete 四种方法来表示。

URL结尾不应该包含斜杠“/”

这是作为URL路径中处理中最重要的规则之一,正斜杠(/)不会增加语义值,且可能导致混淆。REST API不允许一个尾部的斜杠,不应该将它们包含在提供给客户端的链接的结尾处。

许多Web组件和框架将平等对待以下两个URI:

http://api.canvas.com/shapes/

http://api.canvas.com/shapes

但是,实际上URI中的每个字符都会计入资源的唯一身份的识别中。

两个不同的URI映射到两个不同的资源。如果URI不同,那么资源也是如此,反之亦然。因此,REST API必须生成和传递精确的URI,不能容忍任何的客户端尝试不精确的资源定位。

有些API碰到这种情况,可能设计为让客户端重定向到相应没有尾斜杠的URI(也有可能会返回301 - 用来资源重定向)。

正斜杠分隔符”/“必须用来指示层级关系

rul的路径中的正斜杠“/“字符用于指示资源之间的层次关系。

例如:

http://api.user.com/schools/grades/classes/boys
- 学校中所有的男生

http://api.college.com/students/3248234/courses
- 检索id为3248234的学生学习的所有课程的清单。

应该使用连字符”-“来提高URL的可读性,而不是使用下划线”_”

为了使URL容易让人们理解,请使用连字符”-“字符来提高长路径中名称的可读性。

一些文本查看器为了区分强调URI,常常会在URI下加上下划线。这样下划线”_”字符可能被文本查看器中默认的下划线部分地遮蔽或完全隐藏。

为避免这种混淆,请使用连字符”-“而不是下划线

URL路径中首选小写字母

RFC 3986将URI定义为区分大小写,但scheme 和 host components除外。

URL路径名词均为复数

为了保证url格式的一致性,建议使用复数形式。

RESTful API对资源的操作

对于rest api资源的操作,由HTTP动词表示

CURD操作

  • GET: 获取资源
  • POST: 新建资源
  • PUT:在服务器更新资源(向客户端提供改变后的所有资源)
  • PATCH: 在服务器更新资源(向客户端提供改变的属性)
  • DELETE:删除资源

PATCH
一般不用,用 PUT

资源过滤

在获取资源的时候,有可能需要获取某些“过滤”后的资源,例如指定前10行数据

http://api.user.com/schools/grades/classes/boys?page=1&page-size=10

返回状态码推荐标准HTTP状态码

有很多服务器将返回状态码一直设为200,然后在返回body里面自定义一些状态码来表示服务器返回结果的状态码。由于rest api是直接使用的HTTP协议,所以它的状态码也要尽量使用HTTP协议的状态码。

  • 200 OK 服务器返回用户请求的数据,该操作是幂等的
  • 201 CREATED 新建或者修改数据成功
  • 204 NOT CONTENT 删除数据成功
  • 400 BAD REQUEST 用户发出的请求有问题,该操作是幂等的
  • 401 Unauthoried 表示用户没有认证,无法进行操作
  • 403 Forbidden 用户访问是被禁止的
  • 422 Unprocesable Entity 当创建一个对象时,发生一个验证错误
  • 500 INTERNAL SERVER ERROR 服务器内部错误,用户将无法判断发出的请求是否成功
  • 503 Service Unavailable 服务不可用状态,多半是因为服务器问题,例如CPU占用率大,等等

转载:https://www.colabug.com/228298.html

  • 13
    点赞
  • 110
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
Restful API接口规范主要包括以下几个方面的内容: 1. 使用HTTP方法:Restful API使用HTTP协议的不同方法来表示不同的操作,常用的HTTP方法包括GET(查询)、POST(创建)、PUT(更新)和DELETE(删除)。 2. 资源的命名:API的URL应该使用名词来表示资源,而不是动词。例如,使用"/users"表示用户资源,而不是"/getUser"。 3. 使用合适的HTTP状态码:在API的响应中,应该返回合适的HTTP状态码来表示请求的结果。常用的状态码包括200(成功)、201(创建成功)、400(请求参数错误)、404(资源不存在)和500(服务器内部错误)等。 4. 使用合适的HTTP头部:在API的请求和响应中,应该使用合适的HTTP头部来传递额外的信息。例如,使用"Content-Type"头部来指定请求或响应的数据格式,使用"Authorization"头部来进行身份验证。 5. 使用本控制:如果API需要进行更新或修改,应该采用本控制来管理不同本的接口,以避免对现有客户端的影响。 6. 查询参数和路径参数:对于GET请求,可以使用查询参数来过滤和排序结果;对于URL中需要标识资源的情况,可以使用路径参数来传递。 7. 错误处理:当API发生错误时,应该返回具有明确错误信息的响应,以便客户端进行处理。可以使用统一的错误格式,包括错误码和错误消息。 8. 安全性和权限控制:对于需要进行权限控制的接口,应该使用合适的身份验证和授权机制来保护API的安全性,例如使用Token或OAuth等。 9. 接口文档和示例:为了方便开发者使用和理解API,应该提供详细接口文档和示例代码,包括接口的说明、参数列表、示例请求和响应等。 总之,Restful API接口规范主要关注于使用HTTP方法、命名资源、使用合适的状态码和头部、本控制、错误处理、安全性、权限控制等方面,以提供统一、规范和易用的API接口

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值