ASP.NET Core Web API基础

章节目录

一.ASP.NET Core Web API MVC框架

二.ASP.NET Core 开发 Web API

三.RPC和Restful

一.ASP.NET Core Web API MVC框架

MVC 模式代表 Model-View-Controller（模型-视图-控制器） 模式。这种模式用于应用程序的分层开发。

• Model（模型） - 模型代表一个存取数据的对象或 JAVA POJO。它也可以带有逻辑，在数据变化时更新控制器。
• View（视图） - 视图代表模型包含的数据的可视化。
• Controller（控制器） - 控制器作用于模型和视图上。它控制数据流向模型对象，并在数据变化时更新视图。它使视图与模型分离开。
• 

 

Controller层

Models层 

view层

 运行结果

当修改代码显示在浏览器上

第一种方法：点击调试--》生成代码不调试（点一次）--》点击生成--》生成解决方案（每改变一次代码点击一次）

第二种方法：点击这个图标（热重载）但有个缺点不适合太复杂的代码的改变例如新增或删除一个方法。

二.ASP.NET Core 开发 Web API

控制器类WeatherForecastController.cs 继承自ControllerBase类。我们注意到ASP.NET Core MVC项目中的控制器类继承自Controller类，Controller是ControllerBase类的子类。Controller类中包含View等和MVC中的视图等相关的代码，因此我们在编写Web API 的时候，控制器类一般不需要继承自Controller。

 在WeatherForecastController.cs类中加入[Route("[controller]/[action])"]表示访问的路径

 在方法中前边加入[HttpGet]或者[HttpPost]等等表示可以处理Get或者Post请求了，在WeatherForecastController新增加了一个方法SaveNote方法这个方法把用户提交的内存保存到文本文件中，（方法的返回值为保存的文件名）。

三.RPC和Restful

1.Web API两种风格：面向过程(RPC),面向REST

2.RPC:"控制器/操作方法"的形式把服务器端的代码当成方法去调用。把HTTP当成传输数据的通道，不关心HTTP谓词。通过QueryString,请求报文体给服务器传递数据。

3.REST

REST风格的接口按照HTTP的语义来使用Http协议，所有对资源的操作都是无状态的且可以通过标准的HTTP谓词来进行。

（1）在HTTP中，我们要通过URL进行资源的定位。比如获取id=888的用户信息，我们就像/user/888这个路径发送请求，而要获取id=888的用户的订单列表，访问路径为/user/888/order.

(2)不同的请求方法又被叫做请求谓词获取资源GET,新增资源用POST，整体更新用PUT,删除用DELETE.

(3)在HTTP 中，DELETE、PUT、GET 请求应该是幂等的，而 POST 则不是幂等的。所
胃“幂等”指的是:对于一个接口采用同样的参数请求一次和请求多次的结果是一致的，不会
因为多次请求而产生副作用。例如,“发表评论”功能需要是幂等的，用户填写评论并且单击
中，发布】按钮，评论被插入数据库，但是在返回结果的时候由于网络等问题，用户没有看到发
“成功”的消息，因此用户又单击了一次【发布】按钮，如果最终用户只发布了一条评论，那
么这个操作就是幂等的，而如果用户连续单击两次【发布】按钮就发布了两条评论，这个操作
就不是幂等的。由于网络环境存在不稳定性，当遇到网络故障导致请求失败时，如果接口是幂等的，系统就可以向接口重新发送请求，而不用担心重复发送请求带来副作用。
(4)在 HTTP 中，GET 请求的响应是可以被缓存的，而 DELETE、PUT、POST 请求的响
动作通过 HTTP应是不可以被缓存的。客户端、网关等可以根据情况对 GET 请求的响应进行缓存，从而提升需要注意的性能。
(5)在HTTP 中，服务器端要通过状态码来反映资源获取的结果。比如，客户端要获取 id-8的用户，如果要获取的用户不存在，则服务器返回的状态码为 404，而如果当前客户端没有权限获取这个用户，服务器返回的状态码为 403。再如，对于新增用户请求，如果新增成功，服Restful 服务器返回的状态码为 201。

4.REST的优缺点

优点：耦合性低，兼容性好，提高开发效率，不用关心接口实现细节，相对更规范，更标准，更通用，跨语言支持
缺点：性能不如 RPC 高。

5.Restful中如何传递参数

在进行Restful接口设计的时候，我们需要考虑如何给服务器端传递参数。
在给服务器端传递参数的时候，有URL、QueryString、请求报文体3种主要方式。

通过URL传递更符合 Restful规范，但是如果要传递的参数太多或者内容太长的话，通过URL传递的方式就不太适合。通过QueryString传递比较灵活，但是同样不适合传递太长的内容。
通过请求报文体传递参数不限制内容的长度，而且通过JSON 可以传递复杂的格式，但是只有POST、PUT支持请求报文体。
按照RFC 7231标准，GET、DELETE请求中的报文体是未定义的语义，有的网络设备、软件、开发包会忽略 GET、DELETE 中的报文体，因此我们可以认为GET、DELETE请求不能使用报文体。
在REST中，这3种传递参数方式的意义是不同的。

通过URL传递的参数主要用于对资源进行定位，比如资源的ID、资源的分类ID等。
对于额外的数据，比如分页的页码等应该通过QueryString 传递。
请求报文体应该用来供PUT和POST提交主要数据，比如要更新id＝8的用户的姓名为“杨中科”，我们应该向／Users／8这个路径发送PUT请求，且请求的报文体为｛name：＂杨中科＂｝，这样把要更新的用户的id＝8放到URL中来对资源进行定位，通过请求报id=8文体来告诉服务器具体的更新数据。

对于Web API参数的传递建议如下：

对于保存、更新类的请求一般都是使用POST、PUT请求，把全部参数都放到请求报文体中；
对于DELETE请求，要传递的参数就是一个资源的ID，因此把参数放到QueryString中即可；
对于GET请求，一般参数的内容都不会太长，因此统一通过QueryString传递参数就可以；
当然对于极少数参数内容超过URL限制的请求，由于GET、PUT请求都是幂等的，因此把请求改成通过PUT请求，然后通过报文体来传递参数