标签:ror 方法 trie http key 成功 user 使用 pre
一、REST 接口
在请求层面,REST 规范可以简单粗暴抽象成以下两个规则:
请求 API 的 URL 表示用来定位资源;
请求的 METHOD 表示对这个描述资源进行的操作;
知乎大神Ivony有句话说的好:
URL定位资源,用HTTP动词(GET,POST,DELETE,DETC)描述操作。
在设计web接口的时候,REST主要是用于定义接口名,接口名一般是用名词写,不用动词,那怎么表达“获取”或者“删除”或者“更新”这样的操作呢——用请求类型来区分。
比如,我们有一个friends接口,对于“朋友”我们有增删改查四种操作,怎么定义REST接口?
增加一个朋友,uri: generalcode.cn/v1/friends 接口类型:POST
删除一个朋友,uri: generalcode.cn/va/friends 接口类型:DELETE
修改一个朋友,uri: generalcode.cn/va/friends 接口类型:PUT
查找朋友,uri: generalcode.cn/va/friends 接口类型:GET
注意:这就是REST接口,用url定位资源,用HTTP描述操作
上面我们定义的四个接口就是符合REST协议的,请注意,这几个接口都没有动词,只有名词friends,都是通过Http请求的接口类型来判断是什么业务操作。
在很多系统中,几乎只用 GET 和 POST 方法来完成了所有的接口操作;这个行为类似于全用 DIV 来布局。实际上,我们不只有GET 和 POST 可用,在 REST 架构中,有以下几个重要的请求方法:GET,POST,PUT,PATCH,DELETE。这几个方法都可以与对数据的 CRUD 操作对应起来。
CRUD 是指在做计算处理时的增加(Create)、读取查询(Retrieve)、更新(Update)和删除(Delete)几个单词的首字母简写。即增删改查
GET /api/users ( 表示读取用户列表)
GET 应当实现为一个安全方法。用于获取数据而不应该产生副作用。
他们都应当被实现为幂等方法,即多次同样的更新请求应当对服务器产生同样的副作用。
PUT 和 PATCH 有各自不同的使用场景:
PUT 用于更新资源的全部信息,在请求的 body 中需要传入修改后的全部资源主体;
而 PATCH 用于局部更新,在 body 中只需要传入需要改动的资源字段。
【Delete】,资源的删除,相应的请求 HTTP 方法就是 DELETE。这个也应当被实现为一个幂等的方法。
三、状态码
服务器向用户返回的状态码和提示信息,常见的有以下一些(方括号中是该状态码对应的HTTP动词)。
针对不同操作,服务器向用户返回的结果应该符合以下规范。
标签:ror 方法 trie http key 成功 user 使用 pre
原文地址:https://www.cnblogs.com/lucky-girl/p/9389868.html