.NET 4.0 RESTful Web Service 简介

REST - REpresentational State Transfer (表述性状态转移)

REST 不是一种标准，而是一种在互联网上开发和提供服务的方法（规范）。REST 遵循 Web 应用程序的架构风格，就像用户通过选择链接在 Web 应用程序中进行导航，链接将他们带到下一个页面。REST 基于由唯一 URI 标识的资源。

当我们遵循服务被定义为 REST 所需的标准或特性时，我们可以称该服务为 RESTful。REST 不局限于任何特定的平台，但目前主要通过 HTTP 在 Web 上实现。

REST 的基本特性/约束

客户端服务器

关注点分离（Separation of Concerns）是一种将用户界面与数据存储分离的原则。这使得用户界面能够跨多个平台移植，并通过简化服务器组件来提高可伸缩性。

无状态的

对服务器的每次请求都应包含理解和完成请求所需的所有信息。

可缓存（Cacheable）

对请求的响应中的数据应该是可缓存的/不可缓存的，以便客户端在稍后使用。这可能会提高性能并减少网络流量。

分层系统（Layered System）

可以使用代理服务器或缓存服务器等中间服务器来提高性能或增强安全性。

统一接口（Uniform Interface）

应使用统一接口（如 HTTP GET、POST、DELETE、PUT）来访问资源。

RESTful Web Service 由以下组成

URI

统一资源标识符 (Uniform Resource Identifier) - 这是一种在网络上唯一标识资源的方式。Web 上的每个资源都有一个唯一的标识符——通用标识符（例如，URL）。所有 Web 浏览器、服务器、应用程序都理解这个标识符，这使得它们可以轻松地相互连接和交换信息，而不会出现任何问题。

MIME 类型（MIME Type）

可以是 XML、HTML 和 JSON。

HTTP方法

HTTP 构成了与 Web 上的资源通信的标准方法。GET、PUT、DELETE、POST 是访问资源的几种常用方法。

GET

有助于请求资源的特定表示。

PUT

使用特定表示更新资源。

删除

删除指定资源。

POST

创建新资源。

设计 RESTful 服务

设计基于 REST 的服务的第一步是识别将向外部公开的对象（资源），然后将这些资源映射到 URI。我们不应该专注于设计应用程序的方法；相反，我们应该专注于设计资源及其 URI。REST 可以使用各种数据格式，但 XML 更简单且使用最广泛，JSON 的使用也同样普遍。

.NET 4、REST 和 WCF

WCF 不仅仅是构建基于 SOAP 的服务，它是一个可扩展的框架，具有通用的编程模型和完全可插入的通信基础设施。WCF 运行时最基本的工作是监听来自网络位置的消息，处理这些消息，并将它们传递给应用程序（服务）。使用 .NET 4，开发 REST 应用程序是一项轻松的任务。Microsoft 提供了一个 REST 模板，我们可以使用它来创建新项目，这将创建一个 REST 的基本骨架代码。

从 VS 2010 开始，创建一个新项目，选择一个在线模板，然后选择 WCF。将显示各种选项，选择“WCF REST Service Template 40”。

创建一个返回员工详细信息集合的类。使用 `[WebGet()]` 属性标记我们想要调用的方法。

[ServiceContract] 
[AspNetCompatibilityRequirements(RequirementsMode = 
           AspNetCompatibilityRequirementsMode.Allowed)] 
[ServiceBehavior(InstanceContextMode = InstanceContextMode.PerCall)] 
// NOTE: If the service is renamed, remember to update the global.asax.cs file 
public class Service1
{ 
    // TODO: Implement the collection resource
    // that will contain the SampleItem instances 
    [WebGet(UriTemplate = "")] 
    public IList<EmployeeDetail> GetEmployeeDetail() 
    { 
        IList<EmployeeDetail> employeeDetail = 
                          new List<EmployeeDetail>(); 
        EmployeeDetail empDetail1 = new EmployeeDetail(); 
        empDetail1.EmployeeIdentifier = 123; 
        empDetail1.EmployeeName = "Test1"; 
        empDetail1.ProjectName = "NE"; 
        employeeDetail.Add(empDetail1); 
        EmployeeDetail empDetail2 = new EmployeeDetail(); 
        empDetail2.EmployeeIdentifier = 1234; 
        empDetail2.EmployeeName = "Test2"; 
        empDetail2.ProjectName = "NE"; 
        employeeDetail.Add(empDetail2); 
        return employeeDetail; 
    } 
} 

public class EmployeeDetail 
{ 
    private string employeeName; 
    private int employeeId; 
    private string projectName; 
    public int EmployeeIdentifier
    { 
        get
        { 
            return employeeId; 
        } 
        set 
        { 
            employeeId = value; 
        }
    } 

    public string EmployeeName 
    { 
        get
        { 
            return employeeName; 
        } 
        set
        { 
            employeeName = value; 
        } 
    } 
    
    public string ProjectName 
    { 
        get 
        { 
            return projectName; 
        } 
        set 
        { 
            projectName = value; 
        } 
    } 
}

生成并运行代码。现在访问 URL https://:8422/Service1/。服务返回以下 XML

<ArrayOfEmployeeDetail xmlns="http://schemas.datacontract.org/2004/07/WcfRestService2" 
    xmlns:i="http://www.w3.org/2001/XMLSchema-instance"> 
<EmployeeDetail> 
    <EmployeeIdentifier>123</EmployeeIdentifier> 
    <EmployeeName>Test1</EmployeeName> 
    <ProjectName>NE</ProjectName> 
</EmployeeDetail> 
<EmployeeDetail> 
    <EmployeeIdentifier>1234</EmployeeIdentifier> 
    <EmployeeName>Test2</EmployeeName> 
    <ProjectName>NE</ProjectName> 
</EmployeeDetail> 
</ArrayOfEmployeeDetail> 

安全性与 REST

如果你查看上面的代码，你会注意到其中的缺陷，这个服务没有任何内置的安全措施。但是，当我们构建暴露端点的服务时，应该考虑安全性。RESTful 服务只是 HTTP 端点，因此所有与 HTTP 一起实现的安全性（如 HTTPS、证书）也可以与 REST 一起实现。

有两种托管服务的方式：自托管 Web 服务和与 IIS 等应用程序服务器一起托管的 Web 服务。在自托管 Web 服务中，大部分安全性都应该在代码中处理；另一方面，在 IIS 中托管时，IIS 的设置会处理安全性。

设置端点：自托管服务的安全性

端点的安全性通过 `WebHttpBinding` 的 **Security** 属性来设置。**Security** 属性的类型为 `WebHttpSecurity`，用于确定绑定所需的安全模式以及它所需的客户端凭据类型。`WebHttpSecurity` 有两个属性：`Mode`（类型为 `WebSecurityHttpMode`）和 `Transport`（类型为 `HttpTransportSecurity`）。可以使用 `WebHttpSecurityMode` 指定三个安全级别。

1. 无
2. 传输
3. 仅传输凭据 (TransportCredentialOnly)

`WebHttpBinding.Security.Transport`（类型为 `HttpTransportSecurity`）有助于对客户端进行身份验证。它具有以下三个属性：

• ClientCredentialType（类型为 `HttpClientCredentialType`）
• ProxyCredentialType（类型为 `HttpProxyCredentialType`）
• Releam（String）

`HttpClientCredentialType` 的值可以是以下任一值：`None`、`Basic`、`Digest`、`NTLM`、`Windows`、`Certificate`。

设置端点：部署在 IIS 上的服务的安全性

在 IIS 上托管端点时，请使用 *web.config* 文件进行配置更改。配置可以针对服务运行的虚拟目录进行。我们需要同时了解客户端配置和虚拟目录配置。

Authorization

身份验证后，下一步是授权客户端，他们可以做什么，不能做什么。

1. 模拟 (Impersonation)：通过模拟客户端，授权被委托给另一个层。例如，当客户端尝试向 SQL Server 数据库插入或更新数据时，如果客户端没有权限，SQL Server 会抛出异常，该异常可以反馈给客户端。
2. 基于角色的 (Role based)：通过限制对某些 Windows 用户或组的操作访问来实现授权。

REST 的优点

• 与其它风格的服务相比，REST 风格提供的服务更容易消费，这意味着消费者的学习曲线更低。
• 支持服务 URI 的缓存。
• 组件可以独立部署。
• 轻量级（与使用 WSDL 的 SOAP 相比，SOAP 协议使服务更复杂）。
• 简单的客户端。

REST 的缺点

从开发者的角度来看，主要缺点是它没有元数据。因此，它需要了解实现细节。在安全性方面，RESTful 服务依赖于 HTTP 安全性的安全性。

何时使用 REST

当我们计划设计一个专门用于 Web 的应用程序，并且需要快速的客户端集成时，可以实现 REST。

何时不使用 REST

当设计一个服务导向型架构的应用程序，该应用程序互联多个系统并使用多个传输通道时，最好使用 SOAP。