深入学习ASP.NET Web API：英文原版指南

需积分: 0 57 浏览量更新于2024-07-17 收藏 25.42MB PDF 举报

"这是一本深入讲解ASP.NET Web API的书籍，由Apress出版，适合有一定英语基础的读者。本书涵盖了从基础到高级的各种主题，包括异步编程、HTTP、REST原则、HttpClient的使用，以及如何构建实际的应用程序。书中还涉及了路由、控制器与动作、消息处理器、过滤器、媒体类型格式化器、模型绑定、输入验证、依赖注入和单元测试与集成测试等多个关键概念。" 在《Pro ASP.NET Web API》这本书中，作者逐步引导读者了解和掌握ASP.NET Web API的核心技术。首先，第一章“Introduction to ASP.NET Web API”介绍了Web API的基本概念，阐述了为何选择Web API作为构建RESTful服务的平台，以及它与传统的ASP.NET MVC框架的区别。第二章“Introduction to Asynchronous Programming in .NET”探讨了.NET框架下的异步编程，特别是await/async关键字的使用，这是提高Web API性能的关键，尤其是在处理大量并发请求时。第三章“HTTP, REST, and Hypermedia”深入讲解了HTTP协议和RESTful架构风格，解释了状态码、请求方法、超媒体链接等重要概念，帮助读者理解Web API设计的基础。第四章“HttpClient”则关注于如何使用HttpClient类来与Web API进行通信，它是客户端应用与Web API交互的标准方式。从第五章开始，作者通过一个示例应用程序的构建，逐步展示如何运用Web API的各种特性。这部分内容包括应用程序结构、领域模型的构建、Web API的实现、包装器和Web客户端的开发等，让读者能够在实践中学习。后面的章节依次介绍了Web API的路由系统、控制器和操作、消息处理器的自定义、过滤器机制、媒体类型格式化器与模型绑定的使用，以及如何进行输入验证，确保API的安全性。第十四章“Dependency Resolution”讲述了依赖注入的重要性，如何利用IoC容器实现解耦。最后，第十五章“Unit Testing and Integration Testing”指导读者如何编写单元测试和集成测试，确保代码质量。这本书是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页未读，继续阅读

C_Plus87

粉丝: 14
资源: 11

深入学习ASP.NET Web API：英文原版指南

Apress.Pro.ASP.NET.Web.API.

Apress.ASP.NET.MVC.4.and.the.Web.API.Feb.2013

Apress.Pro.NET.Best.Practices

Apress.ASP.NET.MVC.4.Recipes

Apress.ASP.NET.MVC.4.Recipes.Feb.2013

高清彩版 Apress.Pro.NET.Memory.Management

APress,..NET.Game.Programming.with.DirectX.9.0.pdf

《Apress.Pro.ASP.NET.MVC.3.Framework》PDF版

Apress.Pro.ASP.NET.MVC.2.Framework

Apress.Pro.ASP.NET.MVC.3.Framework

最新资源