REST
REST是“REpresentational State Transfer”的缩写,可以翻译成“表现状态转换”.
Rest是web服务的一种架构风格;
使用HTTP,URI,XML,JSON,HTML等广泛流行的标准和协议;
轻量级,跨平台,跨语言的架构设计;它是一种设计风格,不是一种标准,是一种思想
HTTP协议
HTTP采用简单的请求/响应模式的消息交换旨在实现针对某个Web资源的某种操作。
至于针对资源的操作类型,不外乎CRUD(Create、Retrieve、Update和Delete)而已。
一个HTTP请求除了利用URI标志目标资源之外,还需要通过HTTP方法指名针对资源的操作类型。
HTTP方法:包括GET(查)、POST(增)、PUT(改)、DELETE(删)、HEAD、OPTIONS、TRACE、CONNECTION和PATCH等
Rest架构的主要原则
网络上的所有事物都被抽象为资源
每个资源都有一个唯一的资源标识符
同一个资源具有多种表现形式(xml, json等)
对资源的各种操作不会改变资源标识符
所有的操作都是无状态的
符合REST原则的架构方式即可称为RESTful
为什么会出现Restful?
在Restful之前的操作:(SOAP Web API采用RPC(面向方法Remote Procedure Call)风格,它采用面向功能的架构,所以在设计之初首先需要考虑的是提供怎样的功能。)
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用法:(RESTful Web API采用ROA(面向资源Resouce Oriented Architecture)架构,所以在设计之初首先需要考虑的是有哪些资源可供操作。)
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.
接口定义:
对于Controller,其实你起什么名字都无所谓,前端人员不会去管,只需要知道对于某个数据的增删改查调用哪个Controller就行了,查询就用GET请求,新增就用POST请求,修改就用PUT请求,删除就用DELETE请求,然后商量好传参方式,可以把参数放在URL里,
也可以放在请求体Content里,但是对于业务复杂的项目有个缺点,就是如果一个Controller里需要有多个Get,RESTful就会报错,这时迫不得已只能硬加个参数区分,比如说对于下面3种Get,就不会冲突:
[HttpGet]
public ActionResult Get()
{
...
}
[HttpGet("{id}")]
public ActionResult Get(int id)
{
...
}
[HttpGet("{id}/{we}")]
public ActionResult Get(int id,int we)
{
...
}
以上三种Url请求方式就是
1.http://127.0.0.1/user
2.http://127.0.0.1/user/1
3.http://127.0.0.1/user/1/1
扩展:.NET Core Web api 自定义路由 https://blog.csdn.net/ahilll/article/details/82787240