[WCF REST] Web消息主体风格（Message Body Style）

对于Web HTTP编程模型来说，服务契约中作为操作的方法无须应用OperationContractAttribute特性，只需要根据需要应用WebGetAttribute与WebInvokeAttribute特性即可。前者针对GET HTTP方法，或者则针对其他HTTP方法。WebGetAttribute与WebInvokeAttribute的属性BodyStyle和IsBodyStyleSetExplicitly涉及到“Web消息主体风格”的话题。

[AttributeUsage(AttributeTargets.Method)]
public sealed class WebGetAttribute : Attribute, IOperationBehavior
{
    //其他成员
    public WebMessageBodyStyle BodyStyle { get; set; }
}

[AttributeUsage(AttributeTargets.Method)]
public sealed class WebInvokeAttribute : Attribute, IOperationBehavior
{
    //其他成员
    public WebMessageBodyStyle BodyStyle { get; set; }
}

至于消息主体的风格通过具有如下定义的枚举WebMessageBodyStyle表示。

public enum WebMessageBodyStyle
{
    Bare,
    Wrapped,
    WrappedRequest,
    WrappedResponse
}

我们知道请求消息和回复消息分别是对操作方法输入参数和返回值（输出参数和引用参数）的封装，WebMessageBodyStyle中的Bare表示请求消息和回复消息的主体部分仅仅包含针对输入参数和返回值（输出参数和引用参数）序列化后的内容，而Wrapped则会在外面包装一个基于当前操作的“封套”。枚举项WrappedRequest和WrappedResponse用于单独针对请求消息和回复消息的主体进行封装。

WebGetAttribute与WebInvokeAttribute的属性BodyStyle的默认值为Bare。如果该属性被设置成WrappedRequest，则回复消息主体依然采用Bare风格；如果该属性被设置成WrappedResponse，则请求消息主体依然采用Bare风格。布尔类型的只读属性IsBodyStyleSetExplicitly表示是否针对属性BodyStyle进行了显示设置。

目录 
一、Xml+Bare 
二、Xml+Wrapped 
三、JSON+Bare 
四、JSON+Wrapped 
五、Bare请求消息风格对单一输入的限制 
六、Bare回复消息风格对单一输出的限制

一、Xml + Bare

我们通过之前演示的实例来看看针对不同的消息格式（XML和JSON），请求消息和回复消息的主体在采用不同风格的情况下具有怎样的结构。现在我们对应用在契约接口IEmployees中的Create操作方法上的WebInvokeAttribute进行了如下的修改，即显式地指定了请求消息和回复消息的格式（XML）和主体风格（Bare）。同时也将返回类型从void编程了Employee，并直接将创建的Employee对象返回。

[ServiceContract]
public interface IEmployees
{
    //其他成员
    [WebInvoke(UriTemplate = "/", Method = "POST",
    RequestFormat = WebMessageFormat.Xml,
    ResponseFormat = WebMessageFormat.Xml,
    BodyStyle = WebMessageBodyStyle.Bare)]
    Employee Create(Employee employee);
}

public class EmployeesService : IEmployees
{
    //其他成员
    public Employee Create(Employee employee)
    {
        employees.Add(employee);
        return employee;
    }
}

我们针对如下所示的代码通过服务调用添加一个姓名为“王五”的员工。

using (ChannelFactory<IEmployees> channelFactory = new ChannelFactory<IEmployees>("employeeService"))
{
    IEmployees proxy = channelFactory.CreateChannel();
    proxy.Create(new Employee
    {
        Id         = "003",
        Name       = "王五",
         Grade     = "G9",
        Department = "行政部"
    });
}

针对如上所示的服务调用，由于消息格式和主体风格分别为Xml和Bare，所以作为请求消息和回复消息的主体仅仅是Employee对象被序列化后生成的XML片断，具体内容如下所示。

请求消息主体：
<Create xmlns="http://tempuri.org/">
  <employee xmlns:a="http://www.artech.com/"
        xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
    <a:Department>行政部</a:Department>
    <a:Grade>G9</a:Grade>
    <a:Id>003</a:Id>
    <a:Name>王五</a:Name>
  </employee>
</Create>

回复消息主体：
<CreateResponse xmlns="http://tempuri.org/">
  <CreateResult xmlns:a="http://www.artech.com/"
        xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
    <a:Department>行政部</a:Department>
    <a:Grade>G9</a:Grade>
    <a:Id>003</a:Id>
    <a:Name>王五</a:Name>
  </CreateResult>
</CreateResponse>

二、Xml + Wrapped

现在我们对契约接口略加修改，将应用在操作方法Create上的WebInvokeAttribute特性的属性BodyStyle设置为Wrapped。

[ServiceContract]
public interface IEmployees
{
    //其他成员
    [WebInvoke(UriTemplate = "/", Method = "POST",
    RequestFormat = WebMessageFormat.Xml,
    ResponseFormat = WebMessageFormat.Xml,
    BodyStyle = WebMessageBodyStyle.Wrapped)]
    Employee Create(Employee employee);
}

针对相同的服务调用，请求消息和回复消息将具有如下所示的主体内容。我们可以看出Employee被序列化后生成的XML在请求消息中作为<Create>元素的子元素；对于回复消息来说，Employee被序列化后生成的XML的根元素名称为CreateResult，而不是<Employee>，而整个<CreateResult>内嵌于< CreateResponse >元素中。

请求消息主体：
<Create xmlns="http://tempuri.org/">
  <employee xmlns:a="http://www.artech.com/"
        xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
    <a:Department>行政部</a:Department>
    <a:Grade>G9</a:Grade>
    <a:Id>003</a:Id>
    <a:Name>王五</a:Name>
  </employee>
</Create>

回复消息主体：
<CreateResponse xmlns="http://tempuri.org/">
  <CreateResult xmlns:a="http://www.artech.com/"
        xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
    <a:Department>行政部</a:Department>
    <a:Grade>G9</a:Grade>
    <a:Id>003</a:Id>
    <a:Name>王五</a:Name>
  </CreateResult>
</CreateResponse>

三、JSON+ Bare

上面我们通过实例演示了消息格式为Xml情况下针对不同风格的消息主体的内容差异，现在我们按照相同的方式来讨论当消息格式为JSON的时候，针对不同风格的消息主体在结构上又具有怎样差异。如下面的代码片断所示，我们通过对契约接口的修改将服务操作Create的消息格式和主体风格设置成Json和Bare。

[ServiceContract]
public interface IEmployees
{
    //其他成员
    [WebInvoke(UriTemplate = "/", Method = "POST",
    RequestFormat = WebMessageFormat.Json,
    ResponseFormat = WebMessageFormat.Json,
    BodyStyle = WebMessageBodyStyle.Bare)]
    Employee Create(Employee employee);
}

同样针对之前的服务调用，以JSON形式表示的Employee对象将直接作为请求消息和回复消息的主体部分，具体的内容如下所示。（S1004）

请求消息主体：
{"Department":"行政部","Grade":"G9","Id":"003","Name":"王五"}

回复消息主体：
{"Department":"行政部","Grade":"G9","Id":"003","Name":"王五"}

四、JSON+ Wrapped

我们最后来演示Json消息格式在Wrapped风格下具有怎样的结构，为此我们只需要将应用在Create操作方法上的WebInvokeAttribute特性的BodyStyle属性设置为Wrapped。

[ServiceContract]
public interface IEmployees
{
    //其他成员
    [WebInvoke(UriTemplate = "/", Method = "POST",
    RequestFormat = WebMessageFormat.Json,
    ResponseFormat = WebMessageFormat.Json,
    BodyStyle = WebMessageBodyStyle.Wrapped)]
    Employee Create(Employee employee);
}

如下面的代码所示，由于请求消息和回复消息采用Wrapped风格，表示Employee的JSON对象最终作为最终JSON对象的“employee”属性和“CreateResult”属性。（S1005）

请求消息主体：
{"employee":{"Department":"行政部","Grade":"G9","Id":"003","Name":"王五"}}

回复消息主体：
{"CreateResult":{"Department":"行政部","Grade":"G9","Id":"003","Name":"王五"}}

五、Bare请求消息风格对单一输入的要求

对于Bare消息主体风格来说，意味着对象被序列化后生成的XML或者JSON表示直接作为消息的主体，所以只适用于单一对象。具体来说，只有具有唯一输入参数的操作方法才能将请求消息的主题风格设置为Bare。

[ServiceContract(Namespace = "http://www.artech.com/")]
public interface ICalculator
{
    [WebInvoke(BodyStyle = WebMessageBodyStyle.Bare)]
    double Add( double x,  double y);
}

如上所示的是我们熟悉的计算服务的契约接口的定义。消息主体风格为Bare的操作方法Create具有两个输入参数（x和y），在对实现了该契约接口进行寄宿的时候就会抛出如下图所示的InvalidOperationException异常，提示“约定“ICalculator”的操作‘Add’指定要序列化多个请求正文参数，但没有任何包装元素。如果没有包装元素，至多可序列化一个正文参数。请删除多余的正文参数，或将 WebGetAttribute/WebInvokeAttribute 的 BodyStyle 属性设置为 Wrapped”。

六、Bare回复消息风格对单一输出的要求

由于回复参数是对返回值、引用参数和输出参数的封装，所以当操作方法具有引用参数或者输出参数时不能将回复消息的主体风格设置为Bare。

[ServiceContract(Namespace = "http://www.artech.com/")]
public interface ICalculator
{
    [WebInvoke(BodyStyle = WebMessageBodyStyle.WrappedRequest)]
    void Add( double x,  double y, out double result);
}

同样以计算服务契约为例，现在我们通过如上的方式以输出参数的形式返回加法运算的结果，并将应用在操作方法上的WebInvokeAttribute特性的BodyStyle属性设置为WrappedRequest，这意味着请求消息和回复消息分别采用Wrapped和Bare风格。当我们对实现了该契约接口的服务设施寄宿时会抛出下图所示的InvalidOperationException异常，并提示“约定‘ICalculator’的操作‘Add’至少指定一个响应正文参数不是操作的返回值。当 WebGetAttribute/WebInvokeAttribute 的 BodyStyle 属性设置为 Bare 时，只允许使用返回值。请删除多余的响应正文参数或将 BodyStyle 属性设置为 Wrapped”。

不论是我们采用SOAP还是REST架构风格，运行时框架体系依然不曾改变，终结点也仍旧是通信的核心。在Web HTTP编程模型中，我们采用基于WebHttpBinding绑定的终结点。绑定是一组相关绑定元素的有序组合，绑定的特性与能力决定于它包含的绑定元素，在这里我们通过分析绑定元素的方式来剖析WebHttpBinding绑定与其它绑定有何不同。采用HTTP/HTTPS通信协议的WebHttpBinding具有一些与WSHttpBinding/WS2007HttpBinding相同的属性，在这里我们只关心如下定义的Security属性。

public class WebHttpBinding : Binding, IBindingRuntimePreferences
{
    //其它成员
    public WebHttpSecurity Security { get; }
}
public sealed class WebHttpSecurity
{
    // 其它成员
    public WebHttpSecurityMode Mode { get; set; }
    public HttpTransportSecurity Transport { get; }
}
public enum WebHttpSecurityMode
{
    None,
    Transport,
    TransportCredentialOnly
}

基于SOAP的绑定一般具有两种基本的安全模式，即Message和Transport模式。对于前者，它是完全建立在WS-Security为核心的安全协议之上的，而整个WS-*协议簇都是基于SOAP的，所以自然不能应用在WebHttpBinding上，所以它只能通过HTTPS提供针对Transport模式的安全支持。具体来说，通过枚举WebHttpSecurityMode表示的安全模式具有如下三个选项：

• None：HTTP 请求未使用任何安全性；
• Transport：HTTP 请求使用传输级安全性；
• TransportCredentialOnly：仅提供基于 HTTP 的客户端身份验证。

一、WebHttpBinding的绑定元素

现在我们根据上述三种不同的安全模式创建相应的WebHttpBinding对象，然后通过如下的程序在控制台中答应出所有的绑定元素类型。

static void Main(string[] args)
{
    WebHttpBinding binding = new WebHttpBinding(WebHttpSecurityMode.None);
    ListBindingElements(binding);

    binding = new WebHttpBinding(WebHttpSecurityMode.Transport);
    ListBindingElements(binding);

    binding = new WebHttpBinding(WebHttpSecurityMode.TransportCredentialOnly);
    ListBindingElements(binding);
}
static void ListBindingElements(WebHttpBinding binding)
{
    int index = 1;
    Console.WriteLine(binding.Security.Mode + ":");
    foreach (var element in binding.CreateBindingElements())
    {
        Console.WriteLine("{0}. {1}", index++, element.GetType().FullName);
    }
    Console.WriteLine();
}

上述的程序执行之后会在控制台上产生如下的输出，从中我们不难看出三个WebHttpBinding均由一个消息编码元素和传输元素组成，我们知道这两种绑定元素最所有类型的绑定所必需的。

None：
1. System.ServiceModel.Channels.WebMessageEncodingBindingElement
2. System.ServiceModel.Channels.HttpTransportBindingElement

Transport：
1. System.ServiceModel.Channels.WebMessageEncodingBindingElement
2. System.ServiceModel.Channels.HttpsTransportBindingElement

TransportCredentialOnly：
1. System.ServiceModel.Channels.WebMessageEncodingBindingElement
2. System.ServiceModel.Channels.HttpTransportBindingElement

对于WebHttpBinding的两个绑定元素来说，由于它通过HTTPS提供针对Transport安全的支持，所以当安全模式为Transport时对应的传输绑定元素为HttpsTransportBindingElement，对于其余两种安全模式则直接采用HttpTransportBindingElement作为传输绑定元素。现在我们着重讨论是作为消息编码绑定元素的WebMessageEncodingBindingElement类型，以及它涉及的消息编码机制。

二、消息编码

我们先来看看WebMessageEncodingBindingElement的基本的定义。如下面的代码片断所示，它是MessageEncodingBindingElement的子类，并且具有与TextMessageEncodingElement类似的属性定义。其中MaxReadPoolSize和MaxWritePoolSize表示表示无需分配新的XmlDictionaryReader/XmlDictionaryWriter便可以读取的便可同时读取/写入的最大消息数，默认值分别是64和16。ReaderQuotas属性返回用于约束读取的XML的复杂度的XmlDictionaryReaderQuotas对象，而WriteEncoding属性表示采用的字符编码类型，默认采用UTF-8编码方式。由于WebHttpBinding不使用SOAP，表示消息版本的MessageVersion属性自然返回None，如果我们对该属性进行设置，指定的属性值也只能是MessageVersion.None。

public sealed class WebMessageEncodingBindingElement : MessageEncodingBindingElement,...
{
    //其它成员
    public override MessageEncoderFactory CreateMessageEncoderFactory();

    public bool CrossDomainScriptAccessEnabled {get; set; }
    public WebContentTypeMapper ContentTypeMapper { get; set; }

    public int MaxReadPoolSize { get; set; }
    public int MaxWritePoolSize { get; set; }
    public override MessageVersion MessageVersion { get; set; }
    public XmlDictionaryReaderQuotas ReaderQuotas { get; }
    public Encoding WriteEncoding { get; set; }
}

除此之外，WebMessageEncodingBindingElement具有CrossDomainScriptAccessEnabled 和ContentTypeMapper这两个重要的属性。前者表示是否支持跨域（Corss-Domain）脚本访问，默认值为False。后者类型为WebContentTypeMapper。WebContentTypeMapper用于进行消息的内容类型（Content Type，有时候也成为媒体类型或者MIME类型）与具体的格式（比如XML、JSON等）之间的映射。

public abstract class WebContentTypeMapper
{
    protected WebContentTypeMapper();
    public abstract WebContentFormat GetMessageFormatForContentType(string contentType);
}
public enum WebContentFormat
{
    Default,
    Xml,
    Json,
    Raw
}

如上面的代码所示，WebContentTypeMapper是一个抽象类，包含的唯一的抽象方法GetMessageFormatForContentType用于根据指定的内容类型返回与之匹配的通过枚举WebContentFormat表示的内容格式。WebContentFormat枚举的Xml、JSON和Raw体现了Web HTTP编程模型支持三种基本格式，其中Raw表示原始的二进制。

最终的消息编码/解码工作是通过继承自MessageEncoder的消息编码器实现的，消息编码器又是通过继承自MessageEncoderFactory的编码器工厂创建出来的，而消息编码绑定元素最终通过方法CreateMessageEncoderFactory创建了编码器工厂。对于WebMessageEncodingBindingElement来说，它的CreateMessageEncoderFactory方法会创建一个具有如下定义的WebMessageEncoderFactory对象。

internal class WebMessageEncoderFactory : MessageEncoderFactory
{
    public WebMessageEncoderFactory(Encoding writeEncoding, int maxReadPoolSize,int maxWritePoolSize, XmlDictionaryReaderQuotas quotas,
        WebContentTypeMapper contentTypeMapper, bool javascriptCallbackEnabled);
    public override MessageEncoder Encoder { get; }
    public override MessageVersion MessageVersion { get; }
}

WebMessageEncoderFactory是一个继承自MessageEncoderFactory的内部类型。除了布尔类型的参数javascriptCallbackEnabled对应着WebMessageEncodingBindingElement的属性CrossDomainScriptAccessEnabled之外，WebMessageEncoderFactory的构造函数参数与WebMessageEncodingBindingElement的同名属性一一对应。代表消息版本的MessageVersion属性依然返回None，而真正用于最终消息编码/解码工作的是通过Encoder属性返回的具有如下定义的WebMessageEncoder对象。

internal class WebMessageEncoderFactory : MessageEncoderFactory
{
    private class WebMessageEncoder : MessageEncoder
    {
        //其他成员
        private MessageEncoder TextMessageEncoder { get; }
        private MessageEncoder JsonMessageEncoder { get; }
        private MessageEncoder RawMessageEncoder { get; }
    }
}

如上面的代码片断所示，WebMessageEncoder实际上是内嵌于WebMessageEncoderFactory类型中继承自MessageEncoder的内部类型。WebMessageEncoder本身并不真正地实施消息的编码/解码，最终的消息编码/解码工作是通过三个属性TextMessageEncoder、JsonMessageEncoder和RawMessageEncoder体现的具体消息编码器完成的，而它们又分别对应着通过WebContentFormat枚举表示的三种内容类型Xml、JSON和Raw。

微软在WCF 3.5中就通过提供基于Web HTTP的编程模式使我们很容易地创建基于REST的服务，WCF 4.0中对此进行了较大的改进。为了让读者对REST在WCF中的应用有一个大致的了解，我们先来进行一个简单的实例演示。 [源代码从这里下载]

一、定义服务契约

在这个实例中，我们创建一个简单的服务来管理员工的基本信息。至于实例程序的结构，我们依然采用熟悉的包含三个项目（Service.Interface、Service和Client）的解决方案。如下所示的是定义在Service.Interface中用于表示员工的Employee类的定义，它是一个数据契约。

[DataContract(Namespace="http://www.artech.com/")]
public class Employee
{
    [DataMember]
    public string Id { get; set; }

    [DataMember]
    public string Name { get; set; }

    [DataMember]
    public string Department { get; set; }

    [DataMember]
    public string Grade { get; set; }

    public override string ToString()
    {
        return string.Format("ID: {0,-5}姓名: {1, -5}级别: {2, -4} 部门: {3}",Id, Name, Grade, Department);
    }
}

接下来我们定义了如下一个表示服务契约的接口IEmployeesService。和基于SOAP的服务契约定义不同，我们无需在相应的操作方法上面应用OperationContractAttribute特性，但是应用在接口/类上的ServiceContractAttribute特性仍是必需的。在这里替换OperationContractAttribute特性的分别是WebGetAttribute和WebInvokeAttribute，它们均定义在System.ServiceModel.Web程序集中。

[ServiceContract(Namespace="http://www.artech.com/")]
public interface IEmployees
{
    [WebGet(UriTemplate = "all")]
    IEnumerable<Employee> GetAll();

    [WebGet(UriTemplate = "{id}")]
    Employee Get(string id);

    [WebInvoke(UriTemplate = "/", Method = "POST")]
    void Create(Employee employee);

    [WebInvoke(UriTemplate = "/", Method = "PUT")]
    void Update(Employee employee);

    [WebInvoke(UriTemplate = "{id}", Method = "DELETE")]
    void Delete(string id);
}

契约接口IEmployeesService中定义了5个操作，分别用于实现针对员工数据的获取、添加、修改和删除。按照REST设计原则，我们将被操作的员工信息体现为某种网络资源，而操作类型最好与相应的HTTP方法相匹配。在操作方法中针对资源的操作类型与HTTP方法之间的匹配是通过应用在它们上面的WebGetAttribute和WebInvokeAttribute特性来体现。

WebGetAttribute针对GET方法，而其他的HTTP方法则通过WebInvokeAttribute的Method属性来体现。在IEmployeesService中，两个用于获取员工信息GetAll和Get方法均应用了WebGetAttribute特性，而其他的Create、Update和Delete方法在应用了WebInvokeAttribute特性，并且其Method属性被分别设置为PUT、POST和DELETE。

WebGetAttribute和WebInvokeAttribute和均具有相同的属性UriTemplate，该属性用于定义作为最终操作URI的模板。我们不仅可以通过UriTemplate属性为操作指定一个相对于终结点地址的静态路径，还可以通过占位符实现路径中的动态部分与参数之间的映射。

同样以定义在契约接口IEmployeesService中的5个操作方法为例，如果终结点地址为http://127.0.0.1:3721/employees，由于用于返回所有员工列表的GetAll操作的UriTemplate被设置“All”，所以其地址为http://127.0.0.1:3721/employees。用于返回指定员工ID的Get操作的UriTemplate被设置成“{id}”，意味着我们直接在表示请求地址的URI中指定员工的ID，而它会自动映射为该操作方法的参数id。用于删除某个指定员工的Delete操作具有相同的UriTemplate设置，而用于创建添加新员工和修改现有员工信息的Create和Update操作，由于作为参数的Employee对象具有ID属性，所以直接采用终结点地址。

二、创建/寄宿服务

在控制台程序Service中我们定义了如下一个实现了契约接口IEmployeesService的服务类型EmployeesService。简单 起见，我们直接通过一个静态字段employees表示存储的员工列表，该静态字段在初始化的工作中被添加了两个ID分别为001和002的Employee对象。针对员工信息的获取、添加、修改和删除的操作均在此列表中进行。

public class EmployeesService : IEmployees
{
    private static IList<Employee> employees = new List<Employee>
    {
        new Employee{ Id = "001", Name="张三", Department="开发部", Grade = "G7"},
        new Employee{ Id = "002", Name="李四", Department="人事部", Grade = "G6"}
    };
    public Employee Get(string id)
    {
        Employee employee = employees.FirstOrDefault(e => e.Id == id);
        if (null == employee)
        {
            WebOperationContext.Current.OutgoingResponse.StatusCode =
            HttpStatusCode.NotFound;
        }
        return employee;
    }

    public void Create(Employee employee)
    {
        employees.Add(employee);
    }

    public void Update(Employee employee)
    {
        this.Delete(employee.Id);
        employees.Add(employee);
    }

    public void Delete(string id)
    {
        Employee employee = this.Get(id);
        if (null != employee)
        {
            employees.Remove(employee);
        }
}

    public IEnumerable<Employee> GetAll()
    {
        return employees;
    }
}

值得一提的是，不论是用于获取某个指定ID的员工信息的Get方法，还是用于修改和删除员工记录的Update和Delete方法，当指定ID的员工不存在时都通过WebOperationContext表示当前Web操作上下文的对象将回复状态设置为NotFound（即404 Not Found），这体现了我们的服务是基于Web的。

接下来我们通过自我寄宿的方式对上面定义的EmployeesService服务进行寄宿，下面是相应的配置。我们为寄宿的服务添加了唯一一个终结点，并简单地指定了其ABC三要素。和我们之前配置的终结点不同的是，在这里我们采用的绑定类型为WebHttpBinding。

<configuration>
    <system.serviceModel>
    <services>
        <service name="Artech.WcfServices.Service.EmployeesService">
        <endpoint address="http://127.0.0.1:3721/employees"
                  binding="webHttpBinding"
                  contract="Artech.WcfServices.Service.Interface.IEmployees"/>
        </service>
    </services>
    </system.serviceModel>
</configuration>

最终我们通过如下的程序进行服务的寄宿。之前我们总是使用基于服务类型创建的ServiceHost进行服务寄宿，在这里我们使用的是ServiceHost它的子类WebServiceHost。

using (WebServiceHost host = new WebServiceHost(typeof(EmployeesService)))
{
    host.Open();
    Console.Read();
}

三、进行服务调用

由于我们寄宿的服务完全是基于Web的，所以和普通的Web站点没有本质的区别。由于EmployeesService服务的GetAll和Get操作支持HTTP-GET请求，所以我们完全可以在浏览器中针对操作的地址发起请求，而返回的数据可以直接显示在浏览器上。下图所示的是通过浏览器调用GetAll操作（http://127.0.0.1:3721/employees/all）得到的结果，我们可以看到所有员工的列表以XML的形式返回。

我们也可以通过浏览器调用Get操作并直接通过在地址中指定员工的ID（http://127.0.0.1:3721/employees/001）并得到以XML表示的基于相应员工的信息。下图所示XML正式ID为001的Employee对象序列化后的结果。如果在请求地址中指定一个不存在的ID（比如http://127.0.0.1:3721/employees/003），由于Get方法中指定了回复状态为NotFound，我们会得到类似于访问资源不存在的错误信息，就像访问一个不存在的Web页面一样。

上面我们演示了通过浏览器以HTTP-GET方式请求操作地址的方式从而直接将返回结果呈现出来，现在我们来演示如何使用通过ChannelFactory<TChannel>创建的服务代理进行服务调用。我们首先在作为客户端应用程序的Client项目中创建一个App.config，并定义如下的配置。

<configuration>
  <system.serviceModel>
    <behaviors>
      <endpointBehaviors>
        <behavior name="webBehavior">
          <webHttp />
        </behavior>
      </endpointBehaviors>
    </behaviors>
    <client>
      <endpoint name="employeeService"
        address="http://127.0.0.1:3721/employees"
        behaviorConfiguration="webBehavior"
        binding="webHttpBinding"
        contract="Artech.WcfServices.Service.Interface.IEmployees"/>
    </client>
  </system.serviceModel>
</configuration>

如上面的配置片断所示，我们定义了一个与服务端相匹配的客户端终结点，该终结点上应用了一个WebHttpBehavior终结点行为。WebHttpBehavior可以说是整个Web HTTP编程模型的核心，绝大部分针对Web的支持都是通过该行为实现的。实际上服务端终结点通过WebServiceHost应用了这个终结点行为。

using(ChannelFactory<IEmployees> channelFactory = new ChannelFactory<IEmployees>("employeeService"))
{
    IEmployees proxy = channelFactory.CreateChannel();

    Console.WriteLine("所有员工列表：");
    Array.ForEach<Employee>(proxy.GetAll().ToArray(),employee=>Console.WriteLine(employee));

    Console.WriteLine("\n添加一个新员工（003）：");
    proxy.Create(new Employee
    {
        Id              = "003",
        Name            = "王五",
        Grade           = "G9",
        Department      = "行政部"
    });
    Array.ForEach<Employee>(proxy.GetAll().ToArray(),employee => Console.WriteLine(employee));

    Console.WriteLine("\n修改员工（003）信息：");
    proxy.Update(new Employee
    {
        Id              = "003",
        Name            = "王五",
        Grade           = "G11",
        Department      = "销售部"
    });
    Array.ForEach<Employee>(proxy.GetAll().ToArray(), employee => Console.WriteLine(employee));
    Console.WriteLine("\n删除员工（003）信息：");

    proxy.Delete("003");
    Array.ForEach<Employee>(proxy.GetAll().ToArray(), employee => Console.WriteLine(employee));
}

服务调用程序如上所示，我们模拟了员工的添加、修改和删除。程序之后会在客户端控制台产生如下的输出。

所有员工列表：

所有员工列表：
ID: 001  姓名: 张三   级别: G7   部门: 开发部
ID: 002  姓名: 李四   级别: G6   部门: 人事部

添加一个新员工（003）：
ID: 001  姓名: 张三   级别: G7   部门: 开发部
ID: 002  姓名: 李四   级别: G6   部门: 人事部
ID: 003  姓名: 王五   级别: G9   部门: 行政部

修改员工（003）信息：
ID: 001  姓名: 张三   级别: G7   部门: 开发部
ID: 002  姓名: 李四   级别: G6   部门: 人事部
ID: 003  姓名: 王五   级别: G11  部门: 销售部

删除员工（003）信息：
ID: 001  姓名: 张三   级别: G7   部门: 开发部
ID: 002  姓名: 李四   级别: G6   部门: 人事部

从编程角度来看，我们采用与SOAP服务完全一样的服务调用方式，那么如何反映出服务调用基于Web的本质呢？首先，之前我们能够通过浏览器访问GetAll和Get两个操作可以证明这两个服务操作是基于HTTP-GET的，返回的数据直接以单纯的XML返回，并没有封装成SOAP。为了证明Create、Update和Delete也是完全基于Web的，我们可以通过Fiddler来分析HTTP请求的内容。

如下所示的三段XML片断分别对应着针对上述三个服务操作调用的HTTP请求消息，从这我们可以看出它们就是单纯的针对PUT、POST和DELETE方法的HTTP请求，而传输给服务端的数据直接作为消息的主体，并没有封装成SOAP消息。

Create：
PUT http://jinnan-pc:3721/employees/ HTTP/1.1
Content-Type: application/xml; charset=utf-8
Host: jinnan-pc:3721
Content-Length: 187
Expect: 100-continue
Accept-Encoding: gzip, deflate

<Employee xmlns="http://www.artech.com/" xmlns:i="http://www.w3.org/2001/XMLSchema-instance"><Department>销售部</Department><Grade>G11</Grade><Id>003</Id><Name>王五</Name></Employee>

Update：
POST http://jinnan-pc:3721/employees/ HTTP/1.1
Content-Type: application/xml; charset=utf-8
Host: jinnan-pc:3721
Content-Length: 186
Expect: 100-continue
Accept-Encoding: gzip, deflate

<Employee xmlns="http://www.artech.com/" xmlns:i="http://www.w3.org/2001/XMLSchema-instance"><Department>行政部</Department><Grade>G9</Grade><Id>003</Id><Name>王五</Name></Employee>

Delete：
DELETE http://jinnan-pc:3721/employees/003 HTTP/1.1
Content-Type: application/xml; charset=utf-8
Host: jinnan-pc:3721
Content-Length: 80
Expect: 100-continue
Accept-Encoding: gzip, deflate

分类: [01] 技术剖析

绿色通道：好文要顶已关注收藏该文与我联系 

作者：Artech 
出处：http://artech.cnblogs.com 
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。