WebAPI-处理架构

简介: 问题1:HTTP请求和返回相应的HTTP响应信息之间发生了什么?

带着问题去思考,大家好!

问题1:HTTP请求和返回相应的HTTP响应信息之间发生了什么?

image.png

1:首先是最底层,托管层,位于WebAPI和底层HTTP栈之间

2:其次是 消息处理程序管道层,这里比如日志和缓存。OWIN的引用是将消息处理程序管道的一些功能下移到栈下端的OWIN中间件了。

3:控制器处理,HTTP响应,参数的验证和绑定。

托管层

首先是人生三大哲学问题;

1:是WebAPI和底层HTTP基础结构的接口,分三类(Windows进程,[服务啊,控制台啊]&Web托管[Web hosting,IIS]&OWIN的兼容服务器[Katana])

2:它在架构最底层,托管层,位于WebAPI和底层HTTP栈之间

3:它的职责是负责API托管

比如:ASP.NET管道。HttpListener( HTTP 协议侦听器,https://docs.microsoft.com/zh-cn/dotnet/api/system.net.httplistener?redirectedfrom=MSDN&view=netframework-4.7.2).OWIN宿主。

负责创建HttpRquestMessage,返回HttpResponseMessage.转换为底层网络栈处理。

上面第二类,Web托管说下流程,托管层---HttControllerHandler---WebAPI管道,处理后的消息通过HttpResonseMessage实例复制为HttpResonse,然后在转给Asp.Net管道

消息处理管道

这层跟中间件的概念差不多。它有个扩展点,拦截器。

比如:日志和缓存,Web服务器网管接口,Python的WSGI.

首先要知道这几个类,HttpMessageHandler,DelegatingHandler

image.png

继承Object---HttpMessageHandler--DelegatingHandler--MessageProcessingHandler

抽象方法SendAsync接受HttpRequestMessage实例,返回Task<HttpResponse Message>,异步生成一个HttpResponseMessage.这个方法是基于任务的异步模式。

消息处理程序还需要一个数据成员,保存指向一个内部处理程序的指针和数据流逻辑,把请求和响应从一个处理程序委托给他的内部处理程序,DelegatingHandler定义了InnerHandler属性,将一个处理程序连接到其内部处理程序。

HttpConfiguration.MessageHandlers集合属性定义了消息处理程序委托的顺序。

路由分发

在消息处理程序末端。

有路由分发,HttpRoutingDispatcher类实现。根据匹配的IHTTPRoute类选择转发请求所用的下一个处理程序

和控制器分发:HttpControllerDispatcher类实现。调用ExecuteAsync方法,传入请求消息。

控制器处理

可以直接使用IHttpController,通常做法是从抽象类ApiController进行派生。

数据绑定:

ApiController.ExecuteAsync方法调用一系列HttpParameterBinding实例。将参数添加到HttpActionContext实例的ActionArguments字典中

 

 

相关文章
|
JavaScript API 前端开发
dotnet core webapi +vue 搭建前后端完全分离web架构(一)
架构 服务端采用 dotnet core  webapi   前端采用: Vue + router +elementUI+axios            问题 使用前后端完全分离的架构,首先遇到的问题肯定是跨域访问。
7170 0
|
Web App开发 安全 测试技术
|
Web App开发 API 数据库
|
3天前
|
缓存 负载均衡 JavaScript
探索微服务架构下的API网关模式
【10月更文挑战第37天】在微服务架构的海洋中,API网关犹如一座灯塔,指引着服务的航向。它不仅是客户端请求的集散地,更是后端微服务的守门人。本文将深入探讨API网关的设计哲学、核心功能以及它在微服务生态中扮演的角色,同时通过实际代码示例,揭示如何实现一个高效、可靠的API网关。
|
2天前
|
Dubbo Java 应用服务中间件
服务架构的演进:从单体到微服务的探索之旅
随着企业业务的不断拓展和复杂度的提升,对软件系统架构的要求也日益严苛。传统的架构模式在应对现代业务场景时逐渐暴露出诸多局限性,于是服务架构开启了持续演变之路。从单体架构的简易便捷,到分布式架构的模块化解耦,再到微服务架构的精细化管理,企业对技术的选择变得至关重要,尤其是 Spring Cloud 和 Dubbo 等微服务技术的对比和应用,直接影响着项目的成败。 本篇文章会从服务架构的演进开始分析,探索从单体项目到微服务项目的演变过程。然后也会对目前常见的微服务技术进行对比,找到目前市面上所常用的技术给大家进行讲解。
11 1
服务架构的演进:从单体到微服务的探索之旅
|
1天前
|
Cloud Native 安全 API
云原生架构下的微服务治理策略与实践####
—透过云原生的棱镜,探索微服务架构下的挑战与应对之道 本文旨在探讨云原生环境下,微服务架构所面临的关键挑战及有效的治理策略。随着云计算技术的深入发展,越来越多的企业选择采用云原生架构来构建和部署其应用程序,以期获得更高的灵活性、可扩展性和效率。然而,微服务架构的复杂性也带来了服务发现、负载均衡、故障恢复等一系列治理难题。本文将深入分析这些问题,并提出一套基于云原生技术栈的微服务治理框架,包括服务网格的应用、API网关的集成、以及动态配置管理等关键方面,旨在为企业实现高效、稳定的微服务架构提供参考路径。 ####
15 5
|
4天前
|
监控 API 微服务
后端技术演进:从单体架构到微服务的转变
随着互联网应用的快速增长和用户需求的不断演化,传统单体架构已难以满足现代软件开发的需求。本文深入探讨了后端技术在面对复杂系统挑战时的演进路径,重点分析了从单体架构向微服务架构转变的过程、原因及优势。通过对比分析,揭示了微服务架构如何提高系统的可扩展性、灵活性和维护效率,同时指出了实施微服务时面临的挑战和最佳实践。
20 7