精通ASP.NET Web API：构建高效RESTful服务

webapi

需积分: 10 178 浏览量更新于2024-07-22 收藏 25.45MB PDF 举报

身份认证购VIP最低享 7 折!

30元优惠券

"ASP.NET Web API 技术是微软开发的一款用于构建 HTTP 服务的应用程序框架，主要用于构建 RESTful 风格的服务。本书《Pro ASP.NET WEB API》深入介绍了该框架，涵盖了从基础到高级的各种主题，旨在帮助开发者熟练掌握 ASP.NET Web API 的使用。在第一章《Introduction to ASP.NET Web API》中，读者将了解 Web API 的基本概念，包括为什么选择 Web API，它与传统的 ASP.NET MVC 的区别，以及如何创建第一个 Web API 控制器。本章还涉及了路由配置和基本的 HTTP 请求与响应处理。第二章《Introduction to Asynchronous Programming in .NET》则探讨了异步编程，这是现代网络应用中至关重要的一个方面。通过学习，开发者将理解如何利用 .NET Framework 的 Task 和 async/await 关键字进行高效的异步操作。第三章《HTTP, REST, and Hypermedia》详细讲解了 HTTP 协议、REST 架构风格以及超媒体在 Web API 中的作用。这部分内容对于构建符合 REST 原则的服务至关重要。第四章《HttpClient》介绍了 HttpClient 类，它是用于与 Web API 交互的主要客户端库，包括发送请求、接收响应和处理数据的方法。从第五章开始，书中的示例应用程序逐步展开。从应用结构和领域模型（Chapter 5），到构建 Web API（Chapter 6）、包装和 Web 客户端（Chapter 7），这些章节通过实战演练帮助读者巩固所学知识。接下来的章节详细讨论了路由（Chapter 8）、控制器和动作（Chapter 9）、消息处理器（Chapter 10）、过滤器（Chapter 11）、媒体类型格式化器和模型绑定（Chapter 12）、输入验证（Chapter 13）以及依赖注入（Chapter 14）。这些组件和机制是 ASP.NET Web API 中的核心部分，对构建健壮的 API 服务至关重要。最后，书中还涵盖了性能优化和单元测试及集成测试（Chapter 15 和 Chapter 16），这些都是确保服务质量和可维护性的关键实践。《Pro ASP.NET WEB API》提供了全面且深入的指导，无论你是初学者还是有经验的开发者，都能从中获益，提升在 ASP.NET Web API 开发上的技能。"

资源详情

资源推荐

CHAPTER 1 ■ INTRODUCTION TO ASP.NET WEB API

webHttpBinding in WCF

.NET 3.5 included a binding that was not talking SOAP: webHttpBinding. It was capable of sending or receiving plain

old XML over HTTP (POX) or JSON.

Although this was not RESTful and similar to SOAP, only the POST verb was supported, and it allowed for

consumption of WCF API by JavaScript-enabled devices.

WCF Web APIs

After finishing his work in the Microsoft Extensibility Framework (MEF), Glenn Block joined the WCF Web API team

to create success from the failure of WCF REST. Initial Community Technical Preview (CTP) versions of WCF Web API

received a lot of positive feedback from the community and encouraged the team to move forward. The first preview

was released in October 2010 and the latest one was version 6, which was released in November 2011.

As the work progressed, it became evident that fitting a pure HTTP model into the constraints of WCF/RPC is

very hard, if not impossible. On the other hand, the work involved to make HTTP a first-class citizen of the framework

and exposing all the power as type-safe classes, properties, and methods had a lot more to do with the Web than WCF.

As such, it was decided to rename the framework as ASP.NET Web API and move the work to the ASP.NET team. This

coincided with the release of version 6 in November 2011.

Table 1-3. Impedance Mismatch Between SOAP (RPC/WCF) and HTTP (REST): Comparison of Available Axes of

Conveying Intent or Data

Axis SOAP HTTP

URL fragments Yes, contains endpoint and

method (action)

Yes, contains resource information and

can include many pieces of data

Payload Yes, contains envelope that has a header

and body

Yes

Contract Yes No

URL query string No Yes

Verb No, SOAP header is part of payload Yes

Status code No Yes

Formatting and content

negotiation

No Yes, implemented in Accept header*

Caching No Yes, implemented in headers

Concurrency No Yes, implemented in headers

†

Authentication No, implemented in the payload Yes

Encoding No, although WCF has an encoding axis Yes

Partial response No Yes

Hypermedia No Yes, can be implemented in the

payload or header

*In some cases, resource is modified to denote the formatting. For example, a URL ending with .json to denote JSON

formatting.

†

This is used in conditional PUT requests using an if-match header.

CHAPTER 1 ■ INTRODUCTION TO ASP.NET WEB API

So let’s have a look at the task at hand. The team had to turn this pair (this is just a random HTTP

request/response pair example with the site name anonymized):

POST /ajax/bz HTTP/1.1

Host: www.example.com

Connection: keep-alive

Content-Length: 477

Origin: https://www.example.com

User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) _

Chrome/27.0.1453.116 Safari/537.36

Content-Type: application/x-www-form-urlencoded

Accept: */*

Referer: https://www.example.com/messages/...

Accept-Encoding: gzip,deflate,sdch

Accept-Language: en-GB,en;q=0.8,en-US;q=0.6

Cookie: datr=...

HTTP/1.1 200 OK

Cache-Control: private, no-cache, no-store, must-revalidate

Content-Type: application/x-javascript; charset=utf-8

Expires: Sat, 01 Jan 2000 00:00:00 GMT

Pragma: no-cache

Strict-Transport-Security: max-age=60

Content-Encoding: gzip

Date: Sun, 30 Jun 2013 11:28:31 GMT

Transfer-Encoding: chunked

Connection: keep-alive

...

into some form of this:

public Baaz Foo(Bar bar)

{

...

}

This clearly demonstrates the impedance mismatch between RPC and HTTP and the big task at hand. The initial

approach used to solve this problem was to wrap the input parameter and return value into a generic “envelope:”

public HttpResponseMessage<Baaz> Foo(HttpRequestMessage<Bar> request)

{

...

}

These envelopes would be able to support and supply additional aspects of HTTP request and response while

staying loyal to the type safety of the method parameters.

This in fact was the original approach even after the release of the ASP.NET Web API beta. However, after a while,

it became apparent that maintaining the same generic type for the response through the chain of the HTTP processing

pipeline was impractical. In other words, the content of the response could change while the response was passing

through the HTTP pipeline; hence, having a generic request and response would both pose technical challenges with

the async model as well as not being logically correct.

CHAPTER 1 ■ INTRODUCTION TO ASP.NET WEB API

So the team decided to remove the generic parameter from the request and response and allow the generic

type to be expressed in the Content property (which models the request and response payload or in HTTP jargon

the “entity”). So our example of the action method could be rewritten (we have used the async pattern, which will be

covered in Chapter 2):

public async Task<HttpResponseMessage> FooAsync(HttpRequestMessage request)

{

var bar = await request.Content.ReadAsAsync<Bar>();

...

var response = request.CreateResponse();

response.Content = new ObjectContent<Baaz>(new Baaz());

return response;

}

This model solves the impedance mismatch. But that is not the only solution. ASP.NET Web API uses other

techniques to model other axes not available in an action method. Also it is important to note that unlike ASP.NET

MVC actions, ASP.NET Web API actions can return any type and they do not have to inherit from the ActionResult

type. Let’s examine the ASP.NET Web API architecture to understand those techniques.

ASP.NET Web API Architecture

ASP.NET Web API has a very modern design and takes advantage of the latest features of the .NET Framework. But

at the core, it is built on a simple pipe and filter design pattern and, as we know, simplicity is power. This section will

review the design and architecture of the ASP.NET Web API.

Architectural Features

The ASP.NET Web API team made some key decisions that have led to the framework’s robustness, modularity, and

testability. Some of these decisions include:

• Async all the way: The ASP.NET Web API framework has been designed using the task-based

asynchronous programming model from the top to the bottom. As we’ll see in Chapter 2, this

leads to increased scalability.

• No more HttpContext.Current: Although ASP.NET MVC has wrapped HttpContext inside

HttpContextBase for better testability, ASP.NET Web API takes this even further and stores

all contextual properties of the request in the Request.Properties dictionary. Although

accessing HttpContext in ASP.NET Web API could still work, use of HttpContext.Current

is strongly discouraged due to the possible loss of context in task-based async thread

switching.

• Replicating the same HTTP pipeline in client library as well as server library: This helps with

unifying the programming model as well as ease of integration testing because you can short

circuit the client–server communication and bypass the network by connecting the client

pipeline directly to the server pipeline (this will be covered in Chapter 15).

• Ability to host both in IIS (or development server) and in any nonweb server process (called

self-hosted): Future versions of ASP.NET Web API will have the ability to be hosted in custom

web servers. We’ll look into this in Chapter 17.

剩余603页未读，继续阅读

chenbin520

粉丝: 63
资源: 10

精通ASP.NET Web API：构建高效RESTful服务

使用C#开发你的第一个ASP.NET Web API

Packt.Mastering.ASP.NET.Web.API.2017

Packt.ASP.NET.Web.API

vs2022asp.net.web应用程序

asp.net.core 创建webapi

asp.net core webapi有什么用

asp.net core web api框架

asp.net core web api

Asp.web.net.core 项目要怎么开发 pl-cascader 地址选择器功能

asp.net core webapi 和mvc

dropzone.js asp.net core webapi 编写

.net core web api定义

asp.net webapi快速开发框架

.net core web api

.net core web和.net core web api区别

asp.net core web api identity

webapi2和webapi core 1.0区别大吗

asp.net core webapi案例

asp.net core webapi 实战

使用 ASP.NET Web API 構建超媒體 Web API

最新资源