ASP.NET MVC 4 结合 Web API 开发指南

Web

需积分: 14 10 浏览量更新于2023-03-16 收藏 1.45MB PDF 举报

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

30元优惠券

ASP.NET MVC 4 和 Web API ASP.NET MVC 4 和 Web API 是一本关于使用 ASP.NET MVC 结合 Web API 开发的书籍。下面是根据书籍内容生成的相关知识点： **第 1 章：ASP.NET MVC 作为服务框架** * ASP.NET MVC 是一种基于服务的框架，它可以帮助开发者构建灵活、可扩展的服务。 * ASP.NET MVC 提供了一个完整的服务框架，包括模型、视图和控制器。 * 使用 ASP.NET MVC，可以轻松地构建 RESTful 服务。 **第 2 章：什么是 RESTful？** * RESTful 是一种架构风格，它基于资源来设计 API。 * RESTful 的核心概念是资源、资源标识符、资源操作和状态机。 * 使用 RESTful，可以实现轻量级、灵活的 API 设计。 **第 3 章：设计 REST API** * 设计 REST API 需要考虑资源、操作和状态机等要素。 * 需要明确定义 API 的资源、参数和返回值。 * 使用 ASP.NET MVC，可以轻松地实现 RESTful 服务。 **第 4 章：构建环境和创建源代码树** * 构建环境需要考虑开发环境、测试环境和生产环境等。 * 需要使用版本控制系统来管理源代码。 * 使用 ASP.NET MVC，可以轻松地构建环境和创建源代码树。 **第 5 章：控制器、依赖项和数据库单元** * 控制器是 ASP.NET MVC 的核心组件之一。 * 依赖项是指控制器所需的服务或组件。 * 使用 ASP.NET MVC，可以轻松地实现控制器、依赖项和数据库单元的集成。 **第 6 章：保护服务** * 保护服务是指保护 API 免受未经授权的访问。 * 需要使用身份验证和授权机制来保护服务。 * 使用 ASP.NET MVC，可以轻松地实现服务保护。 **第 7 章：将所有内容结合起来** * 将所有内容结合起来需要考虑服务的整体架构。 * 需要使用 ASP.NET MVC 和 Web API 来实现服务的整体架构。 * 使用 ASP.NET MVC，可以轻松地将所有内容结合起来。 ASP.NET MVC 4 和 Web API 是一本关于使用 ASP.NET MVC 结合 Web API 开发的书籍。书籍涵盖了服务框架、RESTful、API 设计、环境构建、控制器、依赖项、数据库单元、服务保护等方面的知识点。

资源详情

资源推荐

CHAPTER 2 ■ WHAT IS RESTFUL?

But you still must rely on specific messages for operations. In other words, the caller

can’t differentiate between the two different operations available with the /api/tasks

URI—unless the caller already has the contract. You’re still using only the POST HTTP

verb, so the request message itself dictates the desired action.

HTTP Verbs

You must look beyond URIs and their resources to the actions needed by the service.

These actions will help you identify the HTTP verbs you need to use. Continuing to follow

our example, there’s no such thing as a CreateTask HTTP verb. In fact, there’s not even a

Create verb. If you’re going to follow the REST architecture and the HTTP protocol, you

must choose from the verbs available in that protocol, namely:

GET ·

PUT ·

POST ·

DELETE ·

Intuitively, you can quickly eliminate GET and DELETE for the CreateTask action.

But what is the difference in intent between PUT and POST? As shown in Table 2-3, PUT

is designed to create or replace a resource with a known identifier—and hence a known

unique URI. You use a POST when the system is generating the new resource’s identifier.

Table 2-2. Task Service at Level 1 on the RMM

Method URI HTTP verb State changes/contract

CreateTask /api/tasks POST Caller required to know

(e.g., WSDL)

GetTask /api/tasks/1234 POST Caller required to know

(e.g., WSDL)

GetTaskAssignees /api/tasks/1234 POST Caller required to know

(e.g., WSDL)

SearchTasks /api/tasks POST Caller required to know

(e.g., WSDL)

UpdateTask /api/tasks/1234 POST Caller required to know

(e.g., WSDL)

CompleteTask /api/tasks/1234 POST Caller required to know

(e.g., WSDL)

CHAPTER 2 ■ WHAT IS RESTFUL?

Technically speaking, the REST architecture is agnostic about any specific protocol.

That includes the HTTP protocol. In other words, all you need is a protocol that provides

a language and mechanism for describing both states (i.e., representations) and state

changes. However, since this book is about building a REST service with ASP.NET, you’ll

focus on REST with HTTP. Fortunately, the HTTP protocol itself covers most of what you

need. Again, Table 2-3 illustrates the intended use of the verbs within REST.

Let’s walk through some important concepts with this mapping. First, the exact

meaning of each of the four verbs is dependent on the URI. So even though you have only

four verbs, you actually have eight different actions available to you. The difference lies in

whether the URI defines a collection or a unique element.

Second, when creating new instances of the resource (e.g. a new task), PUT is used

with a unique URI in the scenario where the caller generates the new resource’s identifier

before submitting the request to the server. In Table 2-3, the PUT action is used with a

unique element URI to create a new task with the specific identifier, 1234. If instead the

system is to generate the identifier, then the caller uses the POST action and a collection

URI. This also ties into the concept of idempotency.

The PUT and DELETE methods are said to be idempotent; that is, calling them over

and over will produce the same result without any additional side effects. For example,

the caller should be able to call the DELETE action on a specific resource without

receiving any errors and without harming the system. If the resource has already been

deleted, the caller should not receive an error. The same applies to the PUT action. For a

given unique resource (identified by an element URI), submitting a PUT request should

update the resource if it already exists. Or, if it doesn’t exist, the system should create

the resource as submitted. In other words, calling PUT over and over produces the same

result without any additional side effects (i.e., the new task will exist in the system per the

representation provided by the caller, whether the system had to create a new one or it

had to update an existing one).

The GET action is said to be safe. This is not idempotent, per se. Safe means that

nothing in the system is changed at all, which is appropriate for HTTP calls that are meant

to query the system for either a collection of resources or for a specific resource.

Table 2-3. Using HTTP verbs with the Task Resource

HTTP verb (Collection URI)

http://myserver.com/tasks

(Element URI)

http://myserver.com/tasks/1234

GET List of tasks, including URIs to

individual tasks

Get a specific task, identified by the

URI

PUT Replace the entire collection of

tasks

Replace or create the single task

identified by the URI

POST Create a new single task, where

its identifier is generated by the

system

Create a new subordinate under the

task identified by the URI

DELETE Delete the entire collection of

tasks

Delete the tasks identified by the URI

CHAPTER 2 ■ WHAT IS RESTFUL?

It is important that the idempotency of the service’s GET, PUT, and DELETE

operations remain consistent with the HTTP protocol standards. Thus, every effort should

be made to ensure those three actions can be called over and over without error.

Unlike the other three actions, POST is not considered to be idempotent. This is

because POST is used to create a new instance of the identified resource type for every

invocation of the method. Where calling PUT over and over will never result in more

than one resource being created or updated, calling POST will result in new resource

instances—one for each call. This is appropriate for cases where the system must

generate the new resource’s identifier, as well as return it in the response.

As you model your task-management service, you will need to map each resource with

a set of HTTP actions, defining which ones are allowed and which ones aren’t supported.

Now let’s take a new look at the task service. This time around, you’ll use the

available HTTP verbs, which will put you at level 2 on the RMM (see Table 2-4).

Table 2-4. Task Service at Level 2 in the RMM

Method URI HTTP verb State changes/contract

CreateTask /api/tasks POST Caller required to know

(e.g., WSDL)

GetTask /api/tasks/1234 GET Caller required to know

(e.g., WSDL)

GetTaskAssignees /api/tasks/1234/users GET Caller required to know

(e.g., WSDL)

SearchTasks /api/tasks GET Caller required to know

(e.g., WSDL)

UpdateTask /api/tasks/1234 PUT Caller required to know

(e.g., WSDL)

CompleteTask /api/tasks/1234 DELETE Caller required to know

(e.g., WSDL)

At this point, the service is utilizing unique URIs for individual resources, and you’ve

switched to using HTTP verbs instead of custom request message types. That is, each of

the PUT and POST actions mentioned previously will simply take a representation of

a task resource (e.g., XML or JSON). However, the client must still have prior knowledge

of the API in order to traverse the domain and to perform any operations more complex

than creating, updating, or completing a task. In the true nature of the Web, you should

instead fully guide the client, providing all available resources and actions via links and

forms. This is what is meant by “hypermedia as the engine of application state.”

HATEOAS

As you look at Tables 2-3 and 2-4, you can see that certain GET operations will return

collections of resources. One of the guiding principles of REST with HTTP is that callers

make transitions through application state only by navigating hypermedia provided

CHAPTER 2 ■ WHAT IS RESTFUL?

by the server. In other words, given a root or starting URI, the caller should be able to

navigate the collection of resources without needing prior knowledge of the URI scheme.

Thus, whenever a resource is returned from the service, whether in a collection or by

itself, the returned data should include the URI required to turn around and perform

another GET to retrieve just that resource.

Here’s an example of an XML response message that illustrates how each element in

the collection should contain a URI to the resource:

<?xml version="1.0" encoding="utf-8"?>

<Tasks>

</Task>

</Task>

</Tasks>

It is typically appropriate to return only a few attributes or pieces of data when

responding with a collection, such as in the preceding example. Now the caller can use

the URI to query a specific resource to retrieve all attributes of that resource. For example,

the Tasks collection response (as just shown) might only contain the Task’s Id and a URI

to fetch the Task resource. But when calling GET to get a specific Task, the response might

include TaskCategory, DateCreated, TaskStatus, TaskOwner, and so on.

Taking this approach can be a little trickier when using strongly typed model objects

in .NET (or any other OO language). This is because we need to define at least two

different variants of the Task type. The typical pattern is to have a TaskInfo class and

a Task class, where the TaskInfo class exists only to provide basic information about a

Task. The collection might look like this:

<?xml version="1.0" encoding="utf-8"?>

<Tasks>

</TaskInfo>

</TaskInfo>

</Tasks>

And the single resource might look like this:

<?xml version="1.0" encoding="utf-8"?>

<Task Id="1234" Status="Active" DateCreated="2011-08-15" Owner="Sally"

Category="Projects" >

</Task>

CHAPTER 2 ■ WHAT IS RESTFUL?

Utilizing two different types like this is not a requirement for REST or any other

service API-style. You may find that you don’t need to separate collection type definitions

from other definitions. Or, you may find that you need many more than two. It all depends

on the usage scenarios and how many different attributes exist on the resource. For

example, if the Task resource included only five or six attributes, then you probably

wouldn’t create a separate type for the collection objects. But if the Task object were to

include 100 or more attributes (as is typical in any real-life financial application), then it

might be a good idea to create more than one variation of the Task type.

Within the realm of HATEOAS, you also want to guide the user as to the actions

available on a resource. You just saw how you can use a <link> element to provide a

reference for fetching task details. You can expand this concept to include all available

resources and actions. Remember, when browsing a web site, a user needs to have prior

knowledge only of the root address to traverse the entire site. You want to provide a

similar experience to callers in the API.

Here’s what a full HATEOAS-compliant XML response might look like for the

TaskInfo type:

<?xml version="1.0" encoding="utf-8"?>

<Tasks>

</TaskInfo>

</TaskInfo>

</Tasks>

Note that the links available to each task are a little different. This is because you

don’t need to complete an already completed task. Instead, you need to offer a link to

reopen it. Also, you don’t want to allow updates on a completed task, so that link is not

present in the completed task.

LINK phILOSOphY

I want to offer a disclaimer and a word of warning for the topic of links in REST

messages. You find that, over the past several years, the debate over how the HTTP

verbs are supposed to be used can be quite heated at times. This debate also

extends into how to best design URIs to be most RESTful—without degenerating

into SOAP-style API.

剩余140页未读，继续阅读

scy251147

粉丝: 7
资源: 5

ASP.NET MVC 4 结合 Web API 开发指南

ASP.NET MVC 4 and the Web API

ASP.NET MVC4 Web 编程.pdf

ASP.NET MVC 4 and the Web API: Building a REST Service from Start to Finish

分布式应用程序与ASP.NET MVC5: 使用Web API

在ASP.NET MVC中集成Web API开发与应用

使用ASP.NET Web API扩展ASP.NET MVC5应用的RESTful服务

ASP.NET MVC框架：构建Web应用程序

ASP.NET MVC框架: 构建Web应用程序的基础

学习asp.net mvc

asp.net mvc 与 web API的区别和联系

做为一个初学者，如何学习asp.net mvc

asp.net.mvc图书管理系统参考文献资料

asp.net MVC可以和Web API整合使用吗？如果可以请详细描述如何整合使用

怎么在asp.net mvc中使用vue.js

asp.net mvc4开发指南pdf

asp.net mvc4 开发指南

asp.net MVC 通用登录验证模块

asp.net mvc4开发指南 源码

asp.net mvc web api 参数输入多个参数

asp.net mvc 4 开发指南 + pdf

最新资源

asp.net mvc4开发指南源码