rest是一种软件架构风格,如果你们的接口是rest接口,那么就可被认为你们的的接口是restful的,英文名词和形容词的区别。
rest接口是围绕“资源”展开的,利用HTTP的协议,其实rest本也可以和HTTP无关,但是现在大家普遍的使用rest都是依托于HTTP协议。HTTP 的url即资源。
RFC 3986定义了通用的URI语法:
1
|
URI = scheme “://” authority “/” path [ “?” query ][ “#” fragment ]
|
对于rest资源的定义,即URL的定义,是最重要的;想要设计出优雅的、易读的rest 接口,其实还是听不容易的。
在Restful架构中,每个网址代表的是一种资源,所以网址中不能有动词,只能有名词,动词由HTTP的 get、post、put、delete 四种方法来表示。
这是作为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容易让人们理解,请使用连字符”-“字符来提高长路径中名称的可读性。 一些文本查看器为了区分强调URI,常常会在URI下加上下划线。这样下划线”_”字符可能被文本查看器中默认的下划线部分地遮蔽或完全隐藏。 为避免这种混淆,请使用连字符”-“而不是下划线
RFC 3986将URI定义为区分大小写,但scheme 和 host components除外。
为了保证url格式的一致性,建议使用复数形式。
对于rest api资源的操作,由HTTP动词表示
PATCH一般不用,用PUT
在获取资源的时候,有可能需要获取某些“过滤”后的资源,例如指定前10行数据
http://api.user.com/schools/grades/classes/boys?page=1&page-size=10
有很多服务器将返回状态码一直设为200,然后在返回body里面自定义一些状态码来表示服务器返回结果的状态码。由于rest api是直接使用的HTTP协议,所以它的状态码也要尽量使用HTTP协议的状态码。
原文:https://www.cnblogs.com/windy2008/p/11926739.html