Web Api(5)

读ASP.NET Web API 2 框架揭秘小记。

1.RESTful Web Api     

REST是一种架构风格。 REST特征 1.采用URL标识资源 作为资源标识的URL最好具有可读性。 2 使用统一的接口 针对资源的CRUD操作。 3.使用标准的HTTP方法 这样就不用再为具体的Action方法设定针对HTTP方法的约束。4.支持多种资源表示方式 5.无状态性 每次请求都是新的

标准的HTTP方法   Get Post Put Patch  Delete Head Options     

Get 获取资源  POST添加 PUT有修改无添加  局部修改Patch  Delete删除  Head得到描述资源的元数据信息  Options  探测请求 例如跨域资源请求

安全性:Get Head Options  

幂等性(决定了第二个请求是否有效):post非幂等

2.寄宿的本质就是利用一个具体的应用程序为Web Api提供一个运行环境 解决请求的接收和响应的回复。 Web Host就是Web Api的宿主。 ASP.NET 自身的路由系统会成为接收请求的第一道屏障,在将请求递交给ASP.NET Web API自己的消息处理管道之前,路由系统会解析出当前请求访问的目标HttpController和Action的名称。我们需要做的就是根据需求注册相应的路由,这也是采用Web Host寄宿方式所需的唯一操作。

3.跨域  在默认情况下,浏览器因 “ 同源策略 ” 的限制会阻止处理利用跨域Alax调用获取的数据。如果采用Ⅱs Express作为服务器,它总是具有一个独占使用的端口,由于Web API寄宿站点总是采用一个与当前不一致的端口,所以AJax调用发送的总是一个跨域请求。

4.内容协商机制  根据请求携带的相关信息来判断客户端所期望的响应资源表现形式。 XML或者JSON等

5.Ⅱs在默认情况下并不提供针对PUT和DELETE请求的支持。IIS拒绝PUT和DELETE请求是由默认注册的一个名为 “WebDAVModule” 的自定义HttpModule导致的。

如果需要提供对PUT和Delete请求的支持利用如下代码将注册的WebDAVModule移除。

<configuration>
    ...
    <system.webServer>
       <modules runAllManagedModulesForAllRequests="true">
           <remove name="WebDAVModule" />
       </modules>
    </system.webServer>
</configuration>

6.对于Web Host来说,真正的路由功能实际上是由ASP.NET自身的路由系统完成的。ASP.NET MVC的路由完全由ASP.NET路由系统来完成.但是后者并非专门为前者设计,其实它最初是为了帮助Web Form应用实现 “ 请求地址与物理文件的分离 ” 而设计的。

7.表示一个Web页面的Page对象就是一个HttpHandler,它被用于最终处理基于某个.aspx文件的请求。我们可以通过HttpHandler的动态映射来实现请求地址与物理文件路径之间的分离。 实际上ASP.NET路由系统就是采用了这样的实现原理。ASP.NET的 URL路由系统通过一个注册的HttpModule对象实现对请求进行的拦截,然后动态映射一个用于处理当前请求的HttpHandler对象。HttpHandler对请求进行处理并予以响应。 

 8.如果一个Web应用寄宿于Ⅱs下,对于Classic模式下的 IIs7.x以及之前的版本,针对这些静态文件请求直接由Ⅱs来响应,并不会进入ASP.NET的管道.但是对于Integrated模式下的Ⅱs7.5,并且采用ASP.NET集成管道,所有类型的请求都将进入ASP.NET管道.在这种情况下,如果允许URL路由系统路由现有物理文件,针对某个静态文件的请求就有可能被重定向到其他地方,这意味着我们将不能正常访问这些静态文 件。除了采用基于Integrated模式下的Ⅱs作为Web服务器,在采用Visual Sudio提供的 ASP.NET Developmcnt server以及Ⅱs Express(IIs Express和Ⅱs在功能上基本相同)的情况下这种问题依然存在。我们可以通过配置 <modules runAllManagedModulesForAllRequests="true">来解决,但是这将导致无法正常引用一些JS CSS文件。我们可以通过调用RoutoCollection的Ignore方法来注册一些需要让路由系统忽略的路由模板。  例如CSS文件 RouteTable.Routes.Ignore("css/{filename}.css/{*pathInfo}"); = =不过正常情况下不需要单独去某些访问静态文件吧 所以上述情况我平时没见过 做个了解而已。

9.ASP.NET路由系统两个应用:—个就是通过注册路由模板与物理文件路径的映射实现请求地址和物理地址的分离(利用路由模板匹配“入栈”请求进而得到相应的路由数据);另一个则是通过注册的路由规则生成一个相应的URL(根据定义的路由规则和提供的路由变量生成“出栈”URL)。

10.ASP.NET WEB API核心框架是一个独立抽象的消息处理管道。HttpRequestMessage  HttpResponseMessage表示管道处理的请求消息和响应消息。

11.ASP.NET WEB API的 核心框架采用管道式设计,这个用于“ 处理请求响应回复”的管道是一组HttpMessageHandler的有序组合。这是一个“双工管道“,相反方向的请求消息和响应消息同时在这个管道中流动并经过逐个HttpMessageHandler的处理。 

12.具体实现"管道串联"是通过DelegatingHandIer这个类型来完成的。顾名思义, DelegatingHandIer具有委托功能,当它自己负责的消息处理任务完成之后可以委托另一个HttpMessageHandler进行后续的处理。消息处理管道就是由DelegatingHandIer”委托链“构建的(管道尾端的是HttpMessageHandler)。

DelegatingHandIer是一个继承自HttpMessageHandler类的抽象类。前面我们所说的这个被委托的HttpMessageHandler由它的属性InnerHandler表示。

消息管道头部是HttpServer(也是继承HttpMessageHandler) 当头部被创建时,尾部则是通过Dispatcher 属性引用的HttpMessageHandlerr对象 中间是DelegatingHandIer。

13.ASP.NET Web API框架本身只要求它实现IHttpControIler接口即可。

位于管道末端的是一个HttpRoutingDispatcher对象。当SendAsync方法被执行,HttpRoutingDispatcher会利用隶属于它的HttpControllerDispatcher来激活目标HttpController对象,随后调用该对象的ExecuteAsync方法并将返回的Task<HttpResponseMessage>对象作为返回值。

14.控制反转(Inversion of Control,IoC)。简单地说,就是应用本身不负责依赖对象的创建和维护,而是将其交给一个外部容器来负责。这样控制权就由应用转移到了外部IoC容器, 即控制权实现了所谓的反转。比如在类型A中需要使用类型B的实例,而B实例的创建并不由A来负责,而是通过外部容器来创建。通过IoC的方式实现针对目标Controllcr的激活具有重要的意义

IoC往往和另一个名词"依赖注入(Dependency Injection,DI)"联系在—起。所谓依赖注入,就是由外部容器在运行时动态地将依赖的对象注入到组件之中。

DI有三种注入方式构造器注入 属性注入 接口注入。

15.Controller和Action都可以加特性路由   Controller上[Route("api/v1/[controller]")] 也可以控制版本 Action上 [Route("Demo")] 当然还不止于此 可以自己个性的写特性. 特性路由信息体现三个属性 Name,Template和Order属性。其中属性Name和Template表示注册路由的名称和采用的路由模板,Order则体现了对应路由对象被选择的优先级,值越小,优先级越高。子路由对象的DataTokens有3个路由变量,order,actions和precedence 当order相同时,看precedence,precedence的值取决于路由模板中由“/”分割的段的数量和形态。值越小,权重越大,选择优先级越高。   

16.ASP.NET WEB API的Model绑定沿用了ASP.NET MVC。

17.ASP.NET WEB API整个服务端框架处理请求并生成响应的流程总结。

将之前的WEB API消息处理管道和HttpController处理结合,串联起来。

首先,ASP.NET WEB API 的消息处理管道由一组HttpMessageHandler按照一定的顺序构成,而处于两端的HttpMessageHandler分别叫作HttpServer和HttpRoutingDispatcher。表示处理请求的HttpRequestMessage对象会根据由传输层接收到的真正的HTTP请求被创建并从HttpServer传入整个管道。HttpRequestMessage对象最终抵达管道末端的HttpRoutingDispatcher。HttpRoutingDispatcher利用ASP.NET Web API路由系统解析出目标HttpController的名称,并借助于HttpControllerDispatcher对目标HttpController予以激活。HttpController对象自身可以执行,调用ExecuteAsync方法,第一步 目标Action的选择 利用注册的HttpActionSelector根据当前请求选择出目标Action,并且创建一个HttpActionContext作为执行目标Action的上下文,第二步 参数绑定 从描述目标Acton方法的HttpActionDescriptor对象中提取对应的HttpActionBinding对象实施参数绑定,并将绑定的参数列表存储在当前的上下文的ActionArguments属性中。第三步  Action的执行 提取绑定的参数列表并利用注册的HttpActionInvoker来执行目标Action并生成代表响应消息的HttpResponseMessage。最后此HttpResponseMessage对象沿着管道返回,并最终由HttpServer交给传输层对请求进行最终的响应

18.5种Filter类型。

1.AuthenticationFilter

2.AuthorizationFilter 

3.ActionFilter 

4.ExceptionFilter

5.OverrideFilter

19.另外本书还有对安全性,跨域资源,Web API的调用等方面的介绍我没看。

最后,对这本书评价一下就是写的很深,很底层,涉及了很多对象,现在的我还没有能力看懂,看的很浅,很多地方也都跳过了,看不懂= =,以上记录了一些基本的概念,但是本书特别适合需要深入的同学学习!

下次再拿出来读的时候希望能理解的多一点。= =

原文地址:https://www.cnblogs.com/cdjbolg/p/12566962.html