.Net WebAPI知识汇总

最新推荐文章于 2024-02-23 21:38:54 发布

Heschel

最新推荐文章于 2024-02-23 21:38:54 发布

阅读量1.4k

点赞数 5

本文链接：https://blog.csdn.net/Heschel/article/details/129731393

版权

文章目录

一.WebAPI历史
二.搭建ASP.NET Core WebAPI项目

一.WebAPI历史

1.形成原因：

Web API（Web Application Programming Interface）的历史可以追溯到Web服务的起源，Web服务最早出现在1990年代中期。Web服务是一种基于标准Web协议的应用程序接口，使不同的应用程序和平台可以互相交互和通信。最早的Web服务采用SOAP（Simple Object Access Protocol）协议，它使用XML作为消息格式，并使用HTTP作为传输协议。

随着时间的推移，REST（Representational State Transfer）架构风格逐渐成为Web API的主流。REST是一种轻量级的Web服务架构，使用HTTP作为通信协议，并使用基于URL的资源标识符来表示数据。REST API被广泛应用于互联网应用程序和移动应用程序开发中。

在Web API的发展过程中，Microsoft的ASP.NET Web API框架也成为了一个受欢迎的选择，它提供了许多功能强大的特性，如路由、模型绑定、过滤器和格式化器等。

过滤器：https://www.bbsmax.com/A/GBJr1wA3z0/

随着移动应用和云计算技术的迅速发展，Web API的需求和应用场景也在不断扩大和深化。现在，Web API已经成为了许多企业和组织的核心应用程序接口，为各种应用程序和服务提供了高效、安全和可靠的数据交换机制。

2.REST架构详解：

REST（Representational State Transfer）是一种软件架构风格，它的设计目标是提供一种简单、可扩展、灵活和易于理解的Web服务架构。REST的核心理念是将资源表示为URI（Uniform Resource Identifier）并使用HTTP方法（GET、POST、PUT、DELETE等）来对资源进行操作。

REST架构通常包括以下四个组件：

资源（Resource）：在REST中，每个资源都有一个唯一的标识符（URI），它可以用来访问和操作该资源。资源可以是任何东西，如文本、图片、视频、用户数据等等。

[URI（Uniform Resource Identifier）可以被理解为标识某个资源的访问地址。在Web应用程序中，URI通常用于标识和访问Web资源，例如网页、图片、音频、视频等等。URI包含了一个协议（如http、https等）、主机名、端口号和资源路径等信息，通过这些信息可以唯一地标识一个资源并访问它。]
HTTP方法（HTTP Methods）：REST使用HTTP方法来定义对资源的操作。常用的HTTP方法包括GET（获取资源）、POST（创建资源）、PUT（更新资源）和DELETE（删除资源）等。
表示（Representation）：资源可以以多种形式呈现，如JSON、XML、HTML等。客户端可以指定所需的表示形式，服务器则根据客户端请求的表示形式返回数据。
状态转移（State Transfer）：REST架构中的状态转移是指客户端通过对资源的操作来改变其状态。例如，客户端可以通过PUT方法更新资源的状态。

REST架构的优点包括：

简单易懂：REST使用标准HTTP方法和URI来表示资源和操作，易于理解和学习。
可扩展性：REST的设计允许系统可以快速添加和修改资源，而不影响系统的其他部分。
可见性：REST的URI和HTTP方法提供了对资源和操作的清晰可见的表示形式，使其易于测试和调试。
可缓存性：REST的设计允许客户端缓存资源，从而减少服务器负载和提高性能。
松耦合：REST的设计使得客户端和服务器之间的耦合度较低，因此系统的部分可以独立地进行修改和更新。

总之，REST架构是一种简单、灵活、可扩展和易于理解的Web服务架构，已经成为许多企业和组织的首选架构。

3.与Web Service对比：

Web API和 Web Service 都是在 Web 应用程序中提供的编程接口，但它们在实现方式、使用场景和应用范围上有所不同。

Web Service 是一种基于 SOAP（Simple Object Access Protocol）和 XML（Extensible Markup Language）的分布式服务架构，它可以通过 HTTP、HTTPS、SMTP等多种传输协议进行通信。Web Service通常提供的是面向操作的服务，即客户端调用特定的操作（如Add、Delete、Update等）来与服务器进行交互，并使用SOAP协议来打包和传输数据。Web Service在企业应用系统中被广泛使用，例如银行系统、ERP系统等。

Web API是一种基于 REST（Representational State Transfer）架构的编程接口，它使用HTTP协议进行通信，并以JSON、XML等格式返回数据。Web API的设计目标是提供简单、灵活、可扩展和易于理解的接口，以便于客户端通过HTTP方法（如GET、POST、PUT、DELETE等）访问和操作Web资源。Web API通常用于构建 Web 应用程序、移动应用程序、IoT应用程序等。

在具体应用中，Web Service 和Web API有各自的优缺点和使用场景。Web Service 具有良好的互操作性和安全性，可以支持跨平台和多语言的开发，但它的复杂性较高，数据传输效率较低。Web API则具有简单易用、高效快速和可扩展性强等优点，但它的安全性相对较弱，需要开发者自己实现认证和授权机制。

总之，Web Service 和Web API都是在Web应用程序中提供的编程接口，它们各有优缺点和适用场景，开发者应根据具体需求选择合适的技术来实现Web服务。

3.1 Web Service实际使用

1.Web Service 引用Web服务的WSDL文件，该文件包含了Web服务的接口定义和方法列表。您可以通过在Visual Studio中添加Web引用来引用WSDL文件，或者使用命令行工具wsdl.exe来生成代理类文件，接口更新后程序也要相应更新。

接下来，您需要使用代理类文件来实现与Web服务的通信。代理类文件包含了Web服务的客户端代理类，可以直接调用Web服务的方法并传递参数。

// 引用Web服务的WSDL文件
localhost.MyWebService myWebService = new localhost.MyWebService();

// 调用Web服务的方法
string result = myWebService.MyMethod(param1, param2);

// 处理Web服务的返回值
Console.WriteLine(result);

2.客户端总是要更新WSDL文件，繁琐。

4. ASP.NET Web API发展历史

ASP.NET Web API是Microsoft公司推出的一种基于.NET Framework的Web API框架，用于构建基于HTTP协议的RESTful风格的Web服务。下面是ASP.NET Web API的发展历史：

2012年：ASP.NET Web API 1.0发布 ASP.NET Web API 1.0是第一个正式版本，于2012年4月发布。它提供了一种简单、灵活和可扩展的方式来构建基于HTTP协议的Web服务，支持多种数据格式和多种传输协议。
2013年：ASP.NET Web API 2.0发布 ASP.NET Web API 2.0于2013年5月发布，是ASP.NET Web API的重要更新版本。它引入了一些新特性，如Attribute Routing、CORS支持、OData支持、Multipart数据传输等，使得开发Web服务更加方便和灵活。
2014年：ASP.NET Web API 2.1发布 ASP.NET Web API 2.1是ASP.NET Web API的小型更新版本，于2014年4月发布。它包含了一些新特性和修复了一些错误，如路由特性、全局异常处理、MVC模型绑定等。
2015年：ASP.NET Core 1.0发布 ASP.NET Core是Microsoft推出的一个跨平台的Web开发框架，包括ASP.NET Core 、Entity Framework Core、Identity Core等组件。ASP.NET Core 1.0于2015年发布，它与ASP.NET Web API不同，它提供了一种基于中间件和管道的Web开发模式，支持多种操作系统和多种开发工具。
2016年：ASP.NET Core 1.1发布 ASP.NET Core 1.1是ASP.NET Core 的更新版本，于2016年发布。它引入了一些新特性和修复了一些错误，如SignalR支持、.NET Standard支持、多种Web服务器支持等。
2017年：ASP.NET Core 2.0发布 ASP.NET Core 2.0是ASP.NET Core 的重要更新版本，于2017年发布。它引入了一些新特性，如Razor Pages、.NET Core SDK、Entity Framework Core 2.0等，提高了性能和安全性，支持Docker容器等新特性。
2018年：ASP.NET Core 2.1发布 ASP.NET Core 2.1是ASP.NET Core的小型更新版本，于2018年发布。它包含了一些新特性和修复了一些错误，如HTTPS支持、API版本控制、Swagger支持、性能优化等。
2019年：ASP.NET Core 3.0发布，ASP.NET Core 3.0是一个重大的更新版本，带来了许多新的特性和改进，包括Razor Components、端到端的HTTP/2支持、单文件发布、构建API客户端等功能。
.NET 5

.NET 5引入了ASP.NET Core Web API，这是一个轻量级的Web API框架，可以运行在Windows、Linux和macOS等各种平台上。ASP.NET Core Web API提供了许多新的特性和改进，包括更快的性能、更好的开发体验、更多的语言特性和更好的安全性。

.NET 6

.NET 6对ASP.NET Core Web API进行了进一步改进，包括更快的性能、更好的跨平台支持、更多的工具和改进的开发体验。同时，.NET 6还引入了一些新的特性，包括应用程序生命周期事件、WebSocket支持、多版本API支持等。

.NET 7

.NET 7将继续改进ASP.NET Core Web API，包括更快的性能、更好的安全性、更好的开发体验和更多的语言特性。同时，.NET 7还将支持更多的编程语言和平台，包括WASM、iOS和Android等。

.NET 8

.NET 8还未发布，因此我们无法确定它对Web API的变化。但是根据.NET平台的发展趋势和用户需求，可以预见.NET 8将带来更多的创新和改进，使得Web API的开发更加简单、高效和灵活。

总之，随着.NET平台的不断发展和创新，每个新版本都会带来更多的功能和特性，使得Web API的开发更加简单、高效和灵活。同时，每个版本还会解决一些之前版本中存在的问题和不足，为开发者提供更好的开发体验和更好的用户体验，ASP.NET Web API经历了多个版本的升级和改进，为开发者提供了更多的功能和性能，使得开发者可以更方便地构建RESTful Web API，并且在不同的平台和环境中运行和部署。

5.ASP.NET Web API与ASP.NET Core Web API对比

ASP.NET Web API是ASP.NET MVC的一个组件，用于构建基于HTTP协议的Web服务。而ASP.NET Core Web API是在.NET Core平台上构建的轻量级、跨平台的Web API框架。相较于ASP.NET Web API，ASP.NET Core Web API改变了以下几个方面：

跨平台支持：ASP.NET Core Web API可以在多种操作系统上运行，如Windows、Linux和macOS等。
更轻量级：ASP.NET Core Web API相较于ASP.NET Web API更加轻量级，其核心库比较小，同时还提供了一些新的特性和功能。
稳定性：ASP.NET Core Web API通过移除一些过时的特性，简化API设计，提高了稳定性和可靠性。
改进的性能：ASP.NET Core Web API通过一些性能优化，如去除不必要的中间件、改进模型绑定和更好的内存管理等，提高了性能。
内置依赖注入：ASP.NET Core Web API内置依赖注入容器，使得依赖注入更加简单和方便。
新的中间件：ASP.NET Core Web API提供了一些新的中间件，如响应缓存、跨域支持、身份验证和授权等，提高了开发效率。
改进的路由：ASP.NET Core Web API的路由系统更加灵活和易于使用，可以支持更多的路由规则。

总之，ASP.NET Core Web API相较于ASP.NET Web API在跨平台支持、轻量级、稳定性、性能、依赖注入、中间件和路由等方面进行了一系列的改进和优化，使得Web API的开发更加简单、高效和灵活。

二.搭建ASP.NET Core WebAPI项目

1. ASP.NET Core WebAPI基础知识掌握：

C#编程语言：ASP.NET Core Web API使用C#编程语言进行开发，需要掌握C#的基本语法和面向对象编程的相关概念。
.NET Core平台：ASP.NET Core Web API是在.NET Core平台上进行开发的，需要了解.NET Core平台的基本知识，包括.NET Core的体系结构、库和工具等。
HTTP协议：ASP.NET Core Web API是基于HTTP协议进行通信的，需要了解HTTP协议的基本知识，包括HTTP请求和响应的结构、状态码、头部信息和常见的HTTP方法等。
RESTful API设计原则：ASP.NET Core Web API通常使用RESTful API风格进行设计，需要了解RESTful API的设计原则，包括资源、URI、HTTP方法、状态码等。
中间件和管道：ASP.NET Core Web API使用中间件和管道来处理HTTP请求和响应，需要了解中间件和管道的概念和使用方法。
依赖注入：ASP.NET Core Web API内置了依赖注入容器，可以使用依赖注入来管理应用程序中的依赖关系，需要了解依赖注入的基本概念和使用方法。
数据库访问和ORM框架：ASP.NET Core Web API通常需要访问数据库，需要了解数据库访问的基本知识和常用的ORM框架，如SQLSugar等。

1.1 dotNET Core平台的基本知识

.NET Core是一种跨平台的开源框架，用于构建高性能、可扩展和可移植的应用程序。如果想要掌握ASP.NET Core Web API，需要了解.NET Core平台的基本知识，包括以下方面：

.NET Core架构和组件：了解.NET Core的整体架构和主要组件，包括.NET Runtime、基类库、SDK工具等。
开发工具：熟悉.NET Core开发工具，如Visual Studio、Visual Studio Code等。
CLI命令行：掌握.NET Core的CLI命令行工具，如dotnet、NuGet等。
语言支持：了解.NET Core支持的编程语言，如C#、F#等。
平台兼容性：了解.NET Core的跨平台特性和兼容性，支持Windows、Linux和macOS等多种操作系统。
部署和运行：了解如何部署和运行.NET Core应用程序，包括自包含应用程序、Docker容器等。
性能优化：了解.NET Core的性能优化策略，包括异步编程、内存管理、GC优化等。

掌握以上.NET Core平台的基本知识，可以帮助开发人员更好地使用.NET Core平台，实现高性能、可扩展和跨平台的应用程序。

1.1.1 用exe程序启动web服务是属于Docker容器部署吗？

不是。使用exe程序启动web服务是一种常规的部署方式，而不是Docker容器部署。在这种部署方式中，应用程序通常打包成一个可执行文件（.exe），并直接在目标机器上运行。

Docker容器部署是将应用程序及其依赖项打包成一个可移植的容器镜像，然后在Docker引擎中运行，从而提供更高的可移植性和隔离性。在Docker容器中，应用程序和其依赖项被打包成一个独立的容器，可以在任何支持Docker引擎的机器上运行。

尽管这两种部署方式有所不同，但它们都可以用于部署和运行ASP.NET Core Web API应用程序。

1.1.2 Docker容器部署步骤

1.首先，我们需要编写Dockerfile文件，该文件描述了如何构建容器镜像。Dockerfile中包含了应用程序所需的环境和依赖项，以及如何启动应用程序。例如，下面是一个简单的Dockerfile示例：

FROM mcr.microsoft.com/dotnet/sdk:5.0 AS build-env
WORKDIR /app

# Copy csproj and restore as distinct layers
COPY *.csproj ./
RUN dotnet restore

# Copy everything else and build
COPY . ./
RUN dotnet publish -c Release -o out

# Build runtime image
FROM mcr.microsoft.com/dotnet/aspnet:5.0
WORKDIR /app
COPY --from=build-env /app/out .
ENTRYPOINT ["dotnet", "myapp.dll"]

在这个示例中，我们首先从官方的.NET 5.0 SDK镜像开始构建，然后复制项目文件并还原依赖项。接着，我们复制整个应用程序并构建出发布版本。最后，我们使用官方的.NET 5.0运行时镜像构建出最终的容器镜像，并设置启动命令。

2.接下来，我们可以使用Docker CLI来构建容器镜像：

Copy code
docker build -t myapp .

该命令将在当前目录中查找Dockerfile文件，并构建名为myapp的容器镜像。构建过程可能需要一些时间，具体取决于应用程序的大小和依赖项。

构建完成后，我们可以使用以下命令来运行容器：

cssCopy code
docker run -p 8080:80 myapp

该命令将创建一个名为myapp的容器，并将容器的80端口映射到主机的8080端口。这样，我们就可以通过访问http://localhost:8080来访问我们的应用程序了。

以上就是一个简单的使用Docker容器部署ASP.NET Core Web API应用程序的示例。

1.2 HTTP请求和响应结构基本知识

HTTP请求和响应都由三个部分组成：起始行、头部信息和消息主体。起始行包含了HTTP方法、URL、HTTP版本等基本信息。头部信息包含了HTTP请求或响应的附加信息。消息主体包含了HTTP请求或响应的数据，如表单数据、JSON数据等。

HTTP状态码：

HTTP状态码是服务器响应客户端请求时使用的三位数字代码。常见的HTTP状态码及其含义如下：

1xx：信息性状态码，表示服务器已经接收到请求，但仍在处理中。
2xx：成功状态码，表示服务器已经成功处理了请求。
3xx：重定向状态码，表示需要进一步操作以完成请求。
4xx：客户端错误状态码，表示客户端发送的请求有误。
5xx：服务器错误状态码，表示服务器无法完成请求。

HTTP头部信息：

HTTP头部信息用于在HTTP请求或响应中携带附加信息。常见的HTTP头部信息如下：

User-Agent：客户端标识，标识发送请求的客户端软件。
Content-Type：消息主体的类型。
Content-Length：消息主体的长度。
Authorization：用于进行身份验证的信息。
Cookie：包含服务器为客户端分配的cookie。

HTTP方法：

HTTP定义了多种方法，用于指定HTTP请求要执行的操作。常见的HTTP方法如下：

GET：从服务器获取资源。
POST：向服务器提交数据。
PUT：向服务器更新资源。
DELETE：删除服务器上的资源。
PATCH：对服务器上的资源进行部分修改。
OPTIONS：获取服务器支持的HTTP方法和其他选项。
HEAD：与GET方法类似，但不返回消息主体。

以上是HTTP请求和响应的结构、状态码、头部信息和常见的HTTP方法的简要介绍。

1.3 RESTful API设计原则

RESTful API设计原则是指设计和开发符合REST（Representational State Transfer）架构风格的API时应该遵循的一些规范和原则。以下是常见的RESTful API设计原则：

1.基于资源：

RESTful API应该基于资源的概念，即把API的所有操作都视为对资源的增删改查。每个资源都应该由唯一的URI（统一资源标识符）来标识，而API的操作则应该通过HTTP方法来表示。

2.使用HTTP方法：

RESTful API应该使用HTTP方法来表示API的操作。常见的HTTP方法包括GET、POST、PUT、DELETE等。其中，GET用于获取资源，POST用于创建资源，PUT用于更新资源，DELETE用于删除资源。

3.使用HTTP状态码：

RESTful API应该使用HTTP状态码来表示操作的结果。常见的HTTP状态码包括200 OK（成功）、201 Created（资源已创建）、400 Bad Request（请求错误）、404 Not Found（资源不存在）、500 Internal Server Error（服务器错误）等。

4.使用统一接口：

RESTful API应该使用统一的接口来进行资源的操作。即使用统一的URI、HTTP方法和HTTP状态码来表示资源的增删改查等操作。

5.状态无关：

RESTful API应该是状态无关的，即每个请求都应该包含足够的信息来执行操作，而不依赖于之前的操作状态。这也是RESTful API可以实现可伸缩性的一个原因。

6.使用标准格式：

RESTful API应该使用标准格式来进行数据交换，如JSON、XML等。同时，API的响应格式应该与请求格式一致，以便客户端能够正确解析响应数据。

7.支持缓存：

RESTful API应该支持缓存，以减轻服务器负载和提高性能。可以使用HTTP头部信息来控制缓存。

以上是常见的RESTful API设计原则，遵循这些原则可以使API更加清晰、易于理解、可维护和可伸缩。

1.4 ASP.NET Core Web API中间件和管道

在ASP.NET Core Web API中，中间件和管道是两个非常重要的概念。它们可以让我们构建出高度可定制化的Web应用程序。

1.中间件

中间件是ASP.NET Core Web API应用程序中的组件，用于处理请求和响应。中间件可以被认为是一个函数，它可以接收请求、处理请求、生成响应，并把响应传递给下一个中间件或终端处理器。中间件可以被添加、移除、组合和重用，以满足特定的应用程序需求。

ASP.NET Core Web API内置了很多中间件，例如：

Authentication中间件用于验证用户身份；
Routing中间件用于路由请求；
Static Files中间件用于提供静态文件；
CORS中间件用于支持跨域资源共享；
Response Compression中间件用于压缩响应等。

2.管道

管道是指将一系列中间件连接起来，构成一条处理请求和响应的管道。管道可以被认为是一种流水线，将请求从一个中间件传递到下一个中间件，最终到达终端处理器并生成响应。

ASP.NET Core Web API应用程序中的请求处理管道由多个中间件构成。在处理请求时，ASP.NET Core Web API会依次调用管道中的每个中间件，直到遇到一个中间件返回响应为止。

ASP.NET Core Web API中的中间件和管道提供了一种灵活的方式来处理请求和响应，并让我们可以对请求和响应进行自定义处理。通过添加、移除、组合和重用中间件，我们可以构建出高度可定制化的Web应用程序。

1.4.1 中间件与控制器有什么异同？

中间件和控制器都是在ASP.NET Core Web API中处理HTTP请求和响应的重要概念，但它们有不同的作用。

中间件是一段在请求管道中的某个点进行处理的代码，可以对HTTP请求和响应进行处理。它们通常用于处理横跨多个请求的逻辑，例如日志记录、异常处理、安全策略等。中间件可以按照一定的顺序进行排列，形成一个处理管道，每个中间件都可以对请求和响应进行处理，并将请求传递给下一个中间件。

控制器是处理HTTP请求的一种特殊类型的类，它通常包含了处理特定请求的方法。控制器方法可以根据HTTP请求的不同参数进行不同的处理，并返回相应的HTTP响应。它们通常用于处理与业务逻辑相关的请求，例如创建、读取、更新和删除（CRUD）操作。

虽然中间件和控制器都可以处理HTTP请求和响应，但它们的主要区别在于处理的逻辑不同。中间件通常用于处理与请求和响应相关的通用逻辑，而控制器通常用于处理与业务逻辑相关的请求。

2. ASP.NET Core WebAPI项目创建

2.1 项目创建步骤

在Visual Studio中搭建ASP.NET Core Web API的步骤如下：

打开Visual Studio并创建一个新项目。
在“新建项目”对话框中，选择“ASP.NET Core Web应用程序”模板，并设置名称和位置。
选择“API”模板，然后点击“创建”按钮。
Visual Studio会创建一个新的ASP.NET Core Web API项目，并打开“Startup.cs”文件。
在“Startup.cs”文件中，可以进行配置和添加中间件等操作，以满足自己的需求。
在“Controllers”文件夹中添加新的控制器类，用于定义API的行为和路由规则。
在控制器类中添加动作方法，用于处理HTTP请求，并返回相应的结果。
编译并运行应用程序，可以使用浏览器或者其他HTTP客户端工具来测试API的功能。

需要注意的是，在搭建ASP.NET Core Web API项目的过程中，可以选择不同的框架和工具，如.NET Core、Entity Framework Core、Swagger等，以满足不同的开发需求。

2.2 项目代码解析

2.2.1 CreateHostBuilder方法

这段代码是在创建一个 ASP.NET Core Web API 应用程序的 HostBuilder 对象。HostBuilder 是在 ASP.NET Core 应用程序启动时构建和配置应用程序的一种方式，用于创建和配置一个应用程序的主机，以及将各种服务注册到 DI 容器中。

在这段代码中，CreateDefaultBuilder 方法将配置主机所需的一些默认设置。ConfigureWebHostDefaults 方法设置了 WebHost 的默认设置，包括 Kestrel 服务器、WebRoot 和默认路由。最后，UseStartup 方法将 Startup 类指定为应用程序的启动类，这个类用于配置应用程序的服务和中间件。

Program中主方法

	public static IHostBuilder CreateHostBuilder(string[] args) =>
			Host.CreateDefaultBuilder(args)
				.ConfigureWebHostDefaults(webBuilder =>
				{
					webBuilder.UseStartup<Startup>();
				});

	public static void Main(string[] args)
		{
			CreateHostBuilder(args).Build().Run();
		}

2.2.2 ConfigureServices方法

	public void ConfigureServices(IServiceCollection services)
		{
			// services.AddScoped<IMyService, MyService>();
			services.AddControllers();
			//services.AddSwaggerGen(c =>
			//{
			//	c.SwaggerDoc("v1", new OpenApiInfo { Title = "WebApplication3", Version = "v1" });
			//});
		}

1.ASP.NET Core Web API的Startup类中的ConfigureServices方法。在这个方法中，我们可以配置应用程序所需的依赖注入服务。

2.使用了services.AddControllers方法来注册控制器服务，该方法会注册MVC控制器和相关的服务，包括路由和过滤器等。

3.我们还可以使用services.AddSwaggerGen方法添加Swagger文档生成器服务，以便在应用程序中生成API文档。

4.需要注意的是，services.AddScoped<IMyService, MyService>()是一个示例，它注册了一个名为IMyService的服务，并将其实现类MyService注册为服务的实现方式。

这里我们可以看到，ASP.NET Core Web API提供了丰富的依赖注入功能，使我们能够轻松地将服务注册到应用程序中，然后在控制器和其他组件中使用它们。

2.2.3 ConfigureServices与中间件、管道关系

ConfigureServices是ASP.NET Core Web API中的Startup类中的一个方法，用于配置应用程序所需的服务。在这个方法中，我们可以使用依赖注入（DI）容器向应用程序中添加服务并配置服务的生命周期。

与中间件和管道的关系是，中间件和管道是在Configure方法中定义和配置的，而ConfigureServices方法用于为这些中间件和管道提供服务和依赖项。通过使用ConfigureServices方法，我们可以配置和注册一些必要的服务，然后在Configure方法中使用这些服务来添加中间件和管道，从而构建请求处理管道。

例如，如果我们想要使用Identity认证服务，我们需要在ConfigureServices方法中添加Identity服务。然后，在Configure方法中，我们可以添加中间件来启用认证并配置认证选项。这样，我们就可以使用ASP.NET Core Web API中的认证服务来保护API资源。

总之，ConfigureServices方法用于配置应用程序所需的服务，中间件和管道是在Configure方法中定义和配置的，但中间件和管道通常需要使用ConfigureServices方法中提供的服务和依赖项来工作。

中间件的有序排列形成管道。

2.2.4 Configure方法

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
		{
			if (env.IsDevelopment())
			{
				app.UseDeveloperExceptionPage();
				app.UseSwagger();
				app.UseSwaggerUI(c => c.SwaggerEndpoint("/swagger/v1/swagger.json", "WebApplication3 v1"));
			}

			app.UseRouting();

			app.UseAuthorization();

			app.UseEndpoints(endpoints =>
			{
				endpoints.MapControllers();
			});
		}

上面的代码是 Configure 方法的一个例子，Configure 方法主要用于配置应用程序的请求管道，并将中间件添加到该管道中。

具体来说，上面的代码中：

app.UseDeveloperExceptionPage() 方法用于在开发环境下显示异常信息页面。
app.UseSwagger() 和 app.UseSwaggerUI() 方法用于启用 Swagger 文档和 Swagger UI 页面，以便于 API 文档的访问和查看。
app.UseRouting() 方法用于启用路由功能，将请求路由到正确的控制器操作方法。
app.UseAuthorization() 方法用于启用授权功能，确保只有经过授权的用户可以访问 API。
app.UseEndpoints() 方法用于配置应用程序的终端点，并指定将请求路由到哪些控制器操作方法。

总的来说，Configure 方法是 ASP.NET Core 应用程序中请求管道的核心部分，通过添加不同的中间件和配置终端点，可以实现不同的功能和业务逻辑。

2.2.5 launchSettings.json配置

launchSettings.json是ASP.NET Core Web API应用程序的启动配置文件，可以设置应用程序在调试和运行时的行为。

该配置文件可以包含多个配置文件，每个配置文件可以包含不同的应用程序配置。例如，可以在一个配置文件中设置应用程序在生产环境中的行为，另一个配置文件则可以设置应用程序在开发环境中的行为。

在该文件中，可以配置应用程序的启动方式、环境变量、调试端口、SSL证书、应用程序URL等等。

以下是一个简单的launchSettings.json配置示例：

{
  "profiles": {
    "MyWebApi": {
      "commandName": "Project",
      "launchBrowser": true,
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      },
      "applicationUrl": "https://localhost:5001;http://localhost:5000"
    }
  }
}

该配置示例中，定义了一个名为"MyWebApi"的配置文件，该文件将应用程序的环境设置为开发环境（“ASPNETCORE_ENVIRONMENT”: “Development”），并且在启动应用程序时会打开浏览器（“launchBrowser”: true）。

此外，还可以看到应用程序URL配置，应用程序会同时监听https://localhost:5001和http://localhost:5000两个URL。

在Visual Studio中，可以通过项目属性窗口或通过右键单击项目文件并选择“属性”来修改launchSettings.json文件。

{
  "$schema": "http://json.schemastore.org/launchsettings.json",
  "iisSettings": {
    "windowsAuthentication": false,
    "anonymousAuthentication": true,
    "iisExpress": {
      "applicationUrl": "http://localhost:4456",
      "sslPort": 44349
    }
  },
  "profiles": {
    "IIS Express": {
      "commandName": "IISExpress",
      "launchBrowser": true,
      "launchUrl": "swagger",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      }
    },
    "eLimsInterfaceDotNet5": {
      "commandName": "Project",
      "dotnetRunMessages": "true",
      "launchBrowser": true,
      "launchUrl": "swagger",
      "applicationUrl": "https://localhost:5001;http://localhost:5000",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      }
    }
  }
}

2.2.6 appsettings.json配置

在 ASP.NET Core Web API 中，appsettings.json 是一个常用的配置文件，用于存储应用程序的配置信息。通过使用 appsettings.json 文件，我们可以在不重新编译代码的情况下更改应用程序的行为。

在 appsettings.json 中，我们可以设置多个不同的配置属性，例如数据库连接字符串、缓存设置、日志记录设置、授权等等。当应用程序启动时，配置文件中的设置将被读取到内存中，并在应用程序的不同部分中使用。

以下是一个示例 appsettings.json 文件：

{
  "ConnectionStrings": {
    "DefaultConnection": "Server=localhost;Database=mydatabase;User=sa;Password=mypassword;"
  },
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft": "Warning",
      "Microsoft.Hosting.Lifetime": "Information"
    }
  }
}

在这个示例中，我们可以看到两个配置属性：

ConnectionStrings：用于存储数据库连接字符串的配置属性。
Logging：用于配置应用程序日志记录的属性。

我们可以在代码中通过以下方式来读取这些配置属性：

var connectionString = Configuration.GetConnectionString("DefaultConnection");

var logLevel = Configuration["Logging:LogLevel:Default"];

其中，Configuration 是在 Startup.cs 文件中 ConfigureServices 方法中注入的 IConfiguration 接口实例。

总的来说，appsettings.json 文件是 ASP.NET Core Web API 中重要的配置文件之一，它可以帮助我们在不改变代码的情况下配置应用程序的行为。

2.2.7 编译配置

更改xxx…csproj配置文件

 <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">
    <TargetFramework>net5.0</TargetFramework>
    <AllowUnsafeBlocks>true</AllowUnsafeBlocks>
    <OutputType>Exe</OutputType>
    <ServerGarbageCollection>false</ServerGarbageCollection>
    <ConcurrentGarbageCollection>true</ConcurrentGarbageCollection>
    <AppendTargetFrameworkToOutputPath>Debug</AppendTargetFrameworkToOutputPath>
    <OutputPath>bin\Debug\</OutputPath>
    <Platforms>AnyCPU;x86</Platforms>
  </PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|AnyCPU'">
    <TargetFramework>net5.0</TargetFramework>
    <AllowUnsafeBlocks>true</AllowUnsafeBlocks>
    <OutputType>Exe</OutputType>
    <ServerGarbageCollection>false</ServerGarbageCollection>
    <ConcurrentGarbageCollection>true</ConcurrentGarbageCollection>
    <AppendTargetFrameworkToOutputPath>Release</AppendTargetFrameworkToOutputPath>
    <OutputPath>bin\Release\</OutputPath>
  </PropertyGroup>

1.OutputPath输出路径

2.ServerGarbageCollection：

Server garbage collection (服务器垃圾回收) 是 .NET Framework 中一种垃圾回收方式，它专为大型多处理器服务器应用程序优化。它的目标是在多处理器服务器上执行垃圾回收，同时最大程度地减少对吞吐量的影响，这使得其在高性能服务器应用程序中使用广泛。

与工作站垃圾回收不同，服务器垃圾回收并不要求在回收时暂停所有线程。它可以使用多个线程同时进行垃圾回收，以充分利用多处理器硬件，从而减少垃圾回收的时间。但是，服务器垃圾回收的开销更高，因为它使用更多的内存和处理器时间来进行垃圾回收。

在 .NET Core 中，默认的垃圾回收方式是基于 Server GC 的。但是，在某些情况下，比如运行在单核计算机或使用的内存较少时，可能会考虑将垃圾回收设置为 Workstation GC，以获得更好的性能。

3.ConcurrentGarbageCollection:

ConcurrentGarbageCollection（并发垃圾回收）是.NET Framework中的一种垃圾回收模式，它可以在不中断应用程序线程的情况下进行垃圾回收。在此模式下，垃圾回收器在与应用程序线程并发执行的情况下，对堆中的垃圾对象进行回收。

相对于传统的垃圾回收模式，ConcurrentGarbageCollection可以显著地减少应用程序暂停的时间，并且对应用程序的吞吐量和响应性能有着积极的影响。

在.NET Core中，ConcurrentGarbageCollection仍然得到支持，并且可以通过配置文件进行启用或禁用。默认情况下，ConcurrentGarbageCollection是启用的。

2.3 实战经验

2.3.1 多级别嵌套参数

1.一般客户要求接口传参，是多级别嵌套形式的json文件；

                     {
                        "requestId":"23543264352155219745",
                        "requestTime":"1585121312559212124",
                        "data":{
                            "Factory":"",
                            "SenderUser":"",
                            "SampleType":"",
                            "LogName":"Test00004",
                                }
                     }

2.运用[FromBody] DataModel指定类型传参；

[HttpPost]
[Route("api/lims/handle")]
 public ReturnDataModel Post([FromBody] DataModel dataModel)      
{
            return new ReturnDataModel();
}

3.类型嵌套

public class DataModel
	{
		public string requestId { get; set; }

		public long requestTime { get; set; }

		public InsideData Data { get; set; } = new InsideData() { }; //内部数据
	}

	public class InsideData
	{
		public string Factory { get; set; }
		public string SampleType { get; set; }
		public string SenderUser { get; set; }
		public string LogName { get; set; }
	}

2.3.2 定向路由

1.访问链接指定：http://127.0.0.1:6000/api/lims/handle

[HttpPost]
[Route("api/lims/handle")]
 public ReturnDataModel Post([FromBody] DataModel dataModel)      
{
            return new ReturnDataModel();
}

        return new ReturnDataModel();

}


3.类型嵌套

```C#
public class DataModel
	{
		public string requestId { get; set; }

		public long requestTime { get; set; }

		public InsideData Data { get; set; } = new InsideData() { }; //内部数据
	}

	public class InsideData
	{
		public string Factory { get; set; }
		public string SampleType { get; set; }
		public string SenderUser { get; set; }
		public string LogName { get; set; }
	}

2.3.2 定向路由

1.访问链接指定：http://127.0.0.1:6000/api/lims/handle

[HttpPost]
[Route("api/lims/handle")]
 public ReturnDataModel Post([FromBody] DataModel dataModel)      
{
            return new ReturnDataModel();
}