Rest架构的主要原则
网络上的所有事物都被抽象为资源
每个资源都有一个唯一的资源标识符（资源的地址 在web中就是URL）同一个资源具有多种表现形式(xml,json等)对资源的各种操作不会改变资源标识符所有的操作都是无状态的符合REST原则的架构方式即可称为RESTful
什么是Restful:
对应的中文是rest式的;Restful web service是一种常见的rest的应用,是遵守了rest风格的web服务;rest式的web服务是一种ROA(The Resource-Oriented Architecture)(面向资源的架构).
为什么会出现Restful
在Restful之前的操作：
http://127.0.0.1/user/query/1 GET 根据用户id查询用户数据
http://127.0.0.1/user/save POST 新增用户
http://127.0.0.1/user/update POST 修改用户信息
http://127.0.0.1/user/delete GET/POST 删除用户信息
RESTful用法：
http://127.0.0.1/user/1 GET 根据用户id查询用户数据
http://127.0.0.1/user POST 新增用户
http://127.0.0.1/user PUT 修改用户信息
http://127.0.0.1/user DELETE 删除用户信息
之前的操作是没有问题的,大神认为是有问题的,有什么问题呢?你每次请求的接口或者地址,都在做描述,例如查询的时候用了query,新增的时候用了save,其实完全没有这个必要,我使用了get请求,就是查询.使用post请求,就是新增的请求,我的意图很明显,完全没有必要做描述,这就是为什么有了restful.
如何使用:
HTTP相应状态码:
关于规范与约束有哪些？
RESTful 架构的核心规范与约束：统一接口
分为四个子约束：
1.每个资源都拥有一个资源标识，每个资源的资源标识可以用来唯一地标明该资源
2.消息的自描述性
3.资源的自描述性。
4.HATEOAS Hypermedia As The Engine Of Application State(超媒体作为应用状态引擎)
一个典型的REST服务不需要额外的文档标示通过哪些URL访问特定类型的资源，而是通过服务端返回的响应来标示到底能在该资源上执行什么样的操作
资源URL的设计？
1.通过URL来表示资源
资源分为主资源与子资源
因为主资源是一类独立的资源 所以主资源应直接放在相对路径下：例如
若要表示主资源的实例：如果实例的ID=1，则这样表示： /goods/1
子资源：
一个实例的子资源可能是一个集合也可能是一个单一的子资源
子资源为图片集合：/goods/1/pictures
子资源为商品折扣的单子子资源：/goods/1/discount
2.单数 vs. 复数
获取用户1的信息，哪种方式更符合RESTful?
/api/users/1
/api/user/1
3.相对路径 vs. 请求参数
极光的RESTful API:
获取用户信息 GET /v1/users/{username} 参数放在路径中
VS
获取用户信息 GET /v1/users?username=xxxxx 拼接的方式
获取应用管理员列表 GET /v1/admins?start={start}&count={count} ？后拼接参数的方式：这种方式一般作为过滤资源
4.使用合适的动词 get delete put post
选择请求接口的方式： get delete
PUT 在服务器更新资源（客户端提供改变后的完整资源）。
POST 在服务器新建一个资源
5.使用标准的状态码
6.选择适当的表示结构
json xml
7.在URI里边带上版本号
有些API在URI里边带上版本号，例如:
若有收获，就点个赞吧
0 人点赞
