今年Tech.Ed北京的主题是云计算（Windows Azure）和Windows Phone 7。相信这不仅体现了微软下一阶段的战略，同时也是业界的主流方向。

WCF团队的演讲也和这个主题密切相关。大家知道WCF在统一编程框架下实现了对五种服务类型的支持：WCF Core Service, WCF Workflow Service, WCF HTTP Service, WCF RIA Service和WCF Data Service。它们分别服务于不同的应用场景，满足服务开发各方面的需求。其中，WCF HTTP服务在云端＋终端的背景下，特别是对mashup聚合服务的需求，以及对多样的终端设备与服务互联互通的应用场景，大有用武之地。

所以我们这次的演讲的主题就是使用WCF开发REST服务，向大家展示WCF HTTP服务的过去，现在和未来，希望这个技术能够为大家所了解，同时也能切实有效地帮助到大家的工作。

下面是简单的介绍，同时也提供了演讲稿的下载供大家参考。

使用WCF开发REST服务 ── 在Windows Server AppFabric 上，在云端

• 简单介绍REST以及其与HTTP的关系，以及REST服务的应用场景；
• WCF HTTP服务的初体验，包括如何开发以及在企业内部环境和云端的部署；
• WCF 4中对REST服务支持的增强，包括简化的配置、更好的缓存、更灵活的格式选择等；
• 隆重推出https://wcf.codeplex.com，这是WCF REST服务向一等公民演进的开始，能够更灵活的选择格式，以及实现对HTTP消息头的控制等等；
• 对下一代WCF的展望。

课程讲义下载

这里还要提一下https://wcf.codeplex.com，WCF CodePlex是WCF研发团队和社区的一个新的沟通渠道。我们会在上面定期发布最新的技术和想法，同时也非常欢迎大家能和我们分享经验和建议，帮助我们构建更加面向用户的技术。

除了演讲，我们团队还有一个动手实验室，在本次技术大会上获得了参会者非常高的评价。在这里我也将简介和指导文档附上，大家有兴趣的也可以动手尝试一下。

Web 服务开发管理新体验 -- WCF4 + Windows Server AppFabric

在本实验中，您先会便捷地创建一个无配置的的Web服务，然后通过Windows Server AppFabric在IIS中集成的全新功能来管理服务。我们将带您管窥WCF和AppFabric的强大功能。

指导文档见附件。

ASI03-HOL-CHS.docx

自从WCF 问世以来， WCF服务的配置一直是广大开发人员所关心的话题。由于WCF作为一个通用服务框架，拥有大量的拓展点，您有时会觉得配置文件过于复杂。在WCF 4.0中，根据各方面收集的用户反馈，WCF团队对WCF的配置做了大量的简化工作，以方便您更快更好的配置WCF服务。下面会给大家主要介绍以下几点：

• 缺省服务配置

• 标准终结点(Standard Endpoint)

• 简化的IIS/ASP.NET中的部署

1.     缺省服务配置

我们都知道，在WCF3.0或3.5中，对每一个服务我们都必须要详细地定义地址，绑定(binding)，契约(contract)，行为(behavior)等一系列的配置，缺一不可。而在WCF4.0中，配置文件中增加了许多缺省选项：从终结点，到绑定，各种行为，都可以被省略。下面是一个简单的WCF服务，运行这个服务甚至不需要配置文件：

运行这个程序结果如下所示：

可以看到，虽然我们在程序中并没有添加终结点，也没有指定绑定，但WCF还是智能地为我们做了这两项配置，那WCF是通过怎样的机制来做这项设定的呢？

1.1.                 缺省的终结点和绑定

事实上，WCF4.0框架会自动检测当前将要运行的服务的终结点个数。根据用户反馈，不少程序员会忘记往当前服务中添加终结点，结果自然是在服务运行的时候跳出错误。在4.0中，如果您指定了服务类型和服务的基本地址，WCF会用这个地址为您自动添加一个终结点。

我们同时可以看到，WCF为这个服务自动选定了BasicHttpBinding。是的，WCF会根据当前URI地址的前缀（在这里是https://），自动挑选对应的缺省绑定。下面是几个常见前缀的默认绑定表：

值得注意的是，如果您为您的服务添加了两个不同的基本地址，WCF会为这两个地址分别添加一个终结点。如果这两个终结点地址的前缀不同的话，您就会自动拥有了两个不同绑定的终结点。

如果您希望改动这里的缺省绑定对应，比如，希望用WsHttpBinding来作为Http前缀的缺省绑定，您只需要在配置文件中添加如下语句：

如果您熟悉WCF ABC (Address，Binding，Contract)话一定会还有一个小疑问：那这边的契约是怎么定义的呢？相信大家一定能够想到，如果当前服务实现了多个WCF 服务接口，WCF会为每一个接口创建一个新的终结点。这边这些终结点会共用一个服务地址和绑定。由于彼此契约不同，这样的行为并不会引起任何冲突。

1.2.                默认的绑定/行为设定

在WCF3.0或3.5中，您需要为您的每一个绑定或者行为取一个名字，然后您的每个终结点需要指定某个定义好的绑定或行为来进行应用。可以想象，当您有几十个甚至几百个服务同时应用相同的绑定或行为的时候，指定这些名字将成为单纯的体力劳动。为了避免这样的情况，WCF4.0 引入了默认绑定/行为的设定。下面是一个默认绑定的例子：

请注意这边我们在定义绑定的时候并没有给这个绑定取名字！在WCF 3.0或3.5版本中是不合法的，但在4.0中，这样的行为表示默认设定。也就是说在当前配置文件中其他用到WsHttpBinding的服务，如果没有指定对应的绑定，那么就会自动采用这个默认绑定，即拥有采用用户名密码认证模式的消息级安全设定。这样的设定方式无疑能够大大的简化程序员的工作量。

WCF的默认行为设定和默认绑定设定的方式类似。同样，如果您在定义完您的服务级行为或者终结点级行为后不特别取一个名字，那么这个行为就能够直接为您所有没指定行为的服务或终结点所采用。

2.     标准终结点

在WCF 3.0或3.5中，为了能够暴露一个元数据端口(metadata endpoint)，您也许常常需要采用如下的方式定义端口：

您会发现对于每个服务，元数据端口的设置其实基本上都是一致的，每次重复写同样的设定其实是没有必要的。因此在WCF 4.0中，我们将一些常用的终结点规范化，引入了一个“标准终结点”的概念。下面就是一个元数据端口的标准终结点的用法：

这里用新关键词“kind”直接指定了这个标准终结点的类型。可以看到这样的写法会为您省下不少工作，同时也减少了出错的可能。另外，和普通的终结点一样，您始终可以在配置文件中对标准终结点的各项设定做出您自己的修改。

下面是WCF4.0 中设定的标准终结点的列表，供您参考：

3.     简化的IIS/ASP.NET中的部署

WCF 4.0针对用户在IIS中的部署做了很多简化工作。如果您曾经在WCF 3.5中为ASP.NET项目添加一个WCF服务，那么先想象一下那时候您需要做的所有操作，然后看一下下面的添加一个WCF 4.0服务的例子：

Service1.svc:

如果您自己创建了一个ASP.NET项目并且添加了上述服务文件，您会发现：

-          您不再需要单独创建一个接口作为服务的契约了。

-          您可以直接把您的服务内容写在.svc文件里面，这样可以直接省下一个.svc.cs(或.vb)文件。

-          您甚至不需要改动Web.Config就能够使得这个服务自动运行。如果您的Web.Config中添加了支持元数据的默认行为，您的服务不需要任何额外设置就拥有了元数据服务支持。

如果您不喜欢用.svc文件而倾向于用.cs或者.vb文件来描述您的服务，您可以反其道而行之，在您的Web.Config文件中添加如下描述：

您可以在这一段中添加所有您的服务描述，在舍弃您所有冗余的.svc文件的同时，也使得您的所有服务有了一个统一的描述地点，管理起来更加方便，可谓一举两得。

是的，一切就那么简单！

4.     小结

以上为大家简单介绍了一下WCF 4.0中关于简化的配置的新特性。希望这些工作能够为您节省更多的时间，做出更好的产品。也希望能够得到您更多关于我们产品的反馈，以便于我们在下一个版本中做出更多的改进和优化。谢谢！

课程简介请参照之前的课程预告博文：https://blogs.msdn.com/wcftoolsteamblogcn/archive/2009/11/27/mvp-day-wcf-rest.aspx

DeckAndSample.zip

    WCF测试客户端（WCF Test Client）是一个用来测试WCF服务程序的调试工具，能够使开发WCF服务更加方便。 本文主要讨论如何在Visual Studio中启用WCF测试客户端的相关技巧。

    在Visual Studio之外打开WCF测试客户端有两种方法：第一种方法是到其所在路径（Visual Studio安装路径\Common7\IDE\WcfTestClient.exe）双击打开。第二种方法是在“Visual Studio命令提示（Visual Studio Command Prompt）”中输入“WcfTestClient”命令，如图1所示:

图1

表1

WCF服务库、WF顺序服务、WF状态机服务：

    启用调试（F5）默认会启动WCF服务主机（WCF Service Host）托管项目中的服务，并且会自动启用WCF测试客户端，请看图2：

图2

    如果希望F5时，不启动WCF测试客户端，可以通过修改项目属性 -> 调试 -> 命令行参数来实现，如图3所示：

图3

WCF服务应用程序、WCF工作流服务应用程序：

    当在“解决方案资源管理器（Solution Explorer）”中，焦点选定在特定服务的.svc或.xamlx文件时，F5会启动WCF测试客户端。请看图4：

图4

    如果希望F5时始终启动IE，可以在.csproj.user文件里增加EnableWcfTestClientForSVC属性配置以禁用WCF测试客户端：

<Project>

  <ProjectExtensions>

    <VisualStudio>

      <FlavorProperties>

        <WebProjectProperties>

          <EnableWcfTestClientForSVC>False</EnableWcfTestClientForSVC>

        </WebProjectProperties>

      </FlavorProperties>

    </VisualStudio>

  </ProjectExtensions>

</Project>

    另外，在.csproj文件里还有EnableWcfTestClientForSVC属性的默认值设置。如果.csproj.user文件没有该属性的相关设置，则该属性则使用.csproj文件里默认值：

<Project>

  <ProjectExtensions>

    <VisualStudio>

      <FlavorProperties>

        <WebProjectProperties>

          <EnableWcfTestClientForSVCDefaultValue>False</EnableWcfTestClientForSVCDefaultValue>

        </WebProjectProperties>

      </FlavorProperties>

    </VisualStudio>

  </ProjectExtensions>

</Project>

    下表是.csproj.user和.csproj文件相关属性的设置和启动客户端类型的逻辑关系：

.csproj.user 文件设置	True	False	未设	未设	未设
.csproj 文件设置	True/False/未设	True/False/未设	True	False	未设
启动 客户端类型	WCF测试客户端	IE	WCF测试客户端	IE	IE

表2

    例如，在一个利用源代码控制的项目组中，.csproj.user文件不会被共享，而.csproj文件会被共享。如果只希望改变个人的WCF测试客户端的启动行为，则应该修改.csproj.user文件；如果希望改变开发这个项目的所有人的启动行为，则应修改.csproj文件。

联合服务库：

    WCF测试客户端并不能对这种服务项目进行测试，所以F5时并不会自动启动WCF测试客户端。

WCF服务（网站）：

    F5时不会自动启动WCF测试客户端。如果希望获得和WCF服务应用程序相同的启动行为，可以修改C:\Users\<username>\AppData\Local\Microsoft\WebsiteCache\websites.xml文件（XP/2003系统中文件在相似位置）：

<DesignTimeData>

  <Website RootUrl="C:\" CacheFolder="WCFService1" EnableWcfTestClientForSVC="true"/>

</DesignTimeData>

    注意在修改websites.xml文件之前请先关闭Visual Studio，否则Visual Studio关闭时会重写覆盖websites.xml文件。

如果你创建寄宿在IIS中的WCF Service网站项目，（图1显示怎样创建这样的网站项目），或者你把你的WCF Web Application项目或者WCF Service网站项目发布或部署到IIS网站服务器上后，你可以用网页浏览器去访问你的网站。如果你在尝试打开这些网页时无法看到正确的页面显示，或者看到错误提示页面(图2是错误提示页面的一个例子: HTTP Error 500.21 – Internal Server Error Handler “svc-Integrated” has a bad module “ManagedPipelineHandler” in its module list)，下面是最常见的问题和解决办法。

                                                         

                                                                   图1                                                                    图2

常见问题与解决办法：

1. 检查IIS是否正确安装和运行

你需要保证你的IIS服务器已经正确安装并正常运行。这里我们不讨论IIS安装的方法(你可你根据你的Windows版本和需要的IIS版本去bing中搜索)， 只给出简单的验证方法。如图2所示，在IE地址栏中输入https://localhost， 如果你看到如图所示的页面或者类似的其他版本IIS的默认页面。那么就说明IIS已经在正常运行了。

 
                                                                      图3

2. 正确注册安装ASP.net

打开Visual Studio命令行提示工具（Start->All Programs->Visual Studio->Visual Studio Tools->Visual Studio Command Prompt， 如果你的OS是Windows Vista及以后的版本，你需要以管理员身份打开），运行”aspnet_regiis.exe -i”。在命令运行完成后重新尝试你的网站。

3. 在IIS中配置正确的Application Pool

在IIS管理工具(IIS Manager)中找到你的Website， 选中。在右侧的面板中点击Basic Settings。 你将看到如图3所示的弹出窗口，其中有你正在使用的Application Pool的信息。 选择IIS管理工具中的Applications Pools节点。选中你在使用的Application Pool， 点击右侧的Basic Settings。 你将看到如图4所示的弹出窗口。确定其中的.NET Framework版本是v4.0.xxxxx。如果不是，这也许就是你看到错误页面的原因。尝试在图2中把它改成v4.0或者在图3中选择”Select…”， 更改成其他的使用.NET Framework v4.0的Application Pool。

                                                  图4     
                              图5

4. 安装注册WCF组件

WCF没有正确的在IIS中注册也许是导致看到错误页面的最常见原因。如果你在安装Visual Studio后才安装IIS， 那么你就很可能遇到这样的问题。打开Visual Studio命令行提示工具（Start->All Programs->Visual Studio->Visual Studio Tools->Visual Studio Command Prompt， 如果你的OS是Windows Vista及以后的版本，你需要以管理员身份打开），运行” ServiceModelReg.exe –ia”。 命令完成后再次访问你的WCF 网站。

如果你在VS2008中开发过WCF服务应用，那你应该使用过集成在其中的WCF开发工具。如果你刚刚开始使用WCF技术，那么可以先阅读这两篇博文对这些WCF开发工具有一个初步的了解：VS2008中的WCF开发工具和VS2008 SP1中WCF开发工具的新功能和增强点。

而在VS2010中我们团队继续为WCF开发工具添加了一系列新功能，希望能为大家提供更好的开发体验。在本文中我将它们逐一罗列出来：

在工作流4.0应用中添加服务引用

当你在一个工作流4.0应用中添加服务引用时，你会看到和以前一样的添加服务引用对话框，可以输入服务的mex或wsdl地址，来生成客户端的代理。不同于以往生成的代码，这时还会生成一组基于XAML的预先配置好的消息活动，和服务中的方法一一对应。当你build你的工作流4.0应用后，这些活动会加到Toolbox中，你可以拖拽使它们成为你的工作流的一部分，并且使用它们来调用服务。

新的WCF工作流服务模板

在.net4.0中，我们新添加了一个新的WCF工作流服务应用模板，帮助创建可长时间运行的工作流服务。

简化配置的WCF服务模板

在WCF4.0中对配置作了简化，包括：使<Services>部分变为可选的，在运行时获得服务的终结点信息；支持服务行为和绑定配置、终结点配置的名字为空等等。所以在4.0的服务模板中也在配置文件中体现了这些简化的配置，以下是WCF服务应用模板的例子：

在WCF和工作流服务应用中F5自动启动WCF测试客户端

在VS2008中，只支持在WCF服务库模板中F5自动启动WCF测试客户端。在VS2010 中，从WCF和工作流服务应用模板创建的WCF服务应用也支持F5自动启动WCF测试客户端。在F5前，请先选中特定服务的.svc或.xamlx文件。

WCF测试客户端支持DataSet类型

WCF测试客户端可以测试WCF服务或者.NET服务中使用的DataSet数据类型。

在WCF和工作流服务应用中全新的服务发布机制

当基于WCF或WCF工作流服务应用模板创建服务应用后，你可以使用全新的发布机制来部署这些服务应用。对于WCF服务库应用还是继续沿用老的发布机制。

Web包：在VS2010中使用MSDeploy打包应用，在Web包中包含了IIS设置信息，相关的web内容，SQL服务器数据库，安全认证，GAC组件，等等。所以Web包可以直接拿到任何服务器上发布。

配置文件转换：在VS2010中引入了XML Document Transform (XDT)，用于灵活地转换开发时或发布时的配置文件。在配置转换文件web.debug.config, web.release.config中存储在web.config文件中需要被替换的内容。

服务发布一步到位：VS2010支持使用IIS远程管理服务把应用发布到远程服务器上。通过创建好特定的profile，可以支持一键式的发布。

以上是对VS2010中WCF工具的简单小结。在后续的文章中，我们将会对其中的一些功能作更详细的描述。

有用的链接：

WCF 和WF新功能:  https://msdn.microsoft.com/en-us/netframework/cc896557.aspx

WCF，WF和AppFabric的网上实验室： https://msdn.microsoft.com/en-us/cc814756.aspx

 我们将于12/10 - 12/11的MVP Day作一个关于WCF REST的讲座。下面是这个讲座的简介和主要方向。希望大家能在会前多给意见，使我们的讲座更有针对性。

主题；使用WCF创建RESTful服务

REST作为一种创建服务架构风格，诞生多年并日趋流行，目前它已经成为一种事实上的标准和许多企业对外发布服务的首选。而微软也在WCF程序框架中开始提供了对REST服务的支持。在这个框架下，我们可以使用WCF技术来方便地创建REST服务。在这个讲座中，我们将介绍REST和WCF的一些基本概念，WCF如何实现REST，以及如何来使用WCF创建一个REST风格的服务。在这个Session中，我们将讨论到：

1.回顾REST的基本概念，它的优势，它的使用情况。

2.通过一个简单的例子引入一个REST风格的程序，同时讨论WCF内部是怎么实现REST框架的

3.演示一个更加具体的例子（微博客服务类似于Twitter）的开发，来一步一步介绍怎么使用WCF开发REST，包括如何处理URI，处理返回的资源格式，设置安全性，在IIS上进行部署等等。

在本篇中，我将会编写客户端的代码去调用我们的服务。 你可能还记得我们上一篇中的Catalog.aspx (应用程序中包含AJAX控件的主要页面)有一个空方法GetData。这个方法在页面初始化的时候，以及在用户在不同商品的不同页面间跳转时被调用。这个方法就是我们要编写代码去调用我们的服务的地方。

注册服务

在我过于深入之前，让我们先短暂停留一会儿。之前我已经编写了一个支持AJAX的WCF服务，但是这究竟意味着什么？从本质上来说，这意味着我们的服务有一个endpoint behavior, 它允许我们创建客户端的AJAX代理类，用几行代码就可以调用我们提供的服务。然后，我们仅仅只需用ScriptManager注册我们的服务就可以实现将这个代理类转化成”流”(stream)传给浏览器。请看下面的代码：

<asp:ScriptManager ID="scriptManager" runat="server">

<Scripts>

<asp:ScriptReference Path="Controls/Catalog.js" />

<asp:ScriptReference Path="Controls/HighlightImageBehavior.js" />

<asp:ScriptReference Path="Controls/ShoppingCart.js" />

<asp:ScriptReference Path="Controls/LoginStatus.js" />

</Scripts>

<Services>

<asp:ServiceReference Path="~/CatalogService.svc" />

</Services>

</asp:ScriptManager>

如果你对ScriptManager不熟悉，他是一个ASP.NET控件，责任是按需分发页面必需的javacript. 如果你有ASP.NET AJAX服务器控件的经验，你会知道它们就是通过ScriptManager来交流他们的脚本需求的。ScriptManager然后给出相应的脚本元素, 在上面的代码中，这个Script节点包含了4个指向专用于这个购物示例应用程序的ASP.NET AJAX客户端库的引用。他们与我们当前的议题(调用WCF服务)并不相关。重要的部分是Service节点。你会注意到这个节点包含了一个指向CatalogService.svc文件路径(即服务的路径)的 ServiceReference。 我们这里主要做的就是把这个支持AJAX的WCF服务注册到ScriptManager中来。

通过注册，我们告诉ScriptManager为网页分发一个指向一个HttpHandler的script元素，它知道如何生成服务的客户端代理。为了展示这一点，我将直接在浏览器中打开这个网页，然后在页面上点击右键，选择”查看源码”。往下翻动，下面那是我找到的内容：

代理类

如果你想看一下客户端代理的代码(你应该看一下)，在你的网页URL后面加上CatalogService.svc/jsdebug。在我的例子中，完整的URL是: https://localhost:50183/ClientStore/CatalogService.svc/jsdebug。打开后你会得到如下的对话框：

我将代理保存到我桌面的本地文件，更名为proxy.js。然后我将这个文件拖放到我的好友Visual Studio中去。以下是我看到的部分:

第一个值得注意的地方是这里的代理利用了ASP.NET 客户端库。在这些库中，我们”.NET化”了JavaScript。 我们添加了命名空间(namespace)，类等一系列概念。如果你对更详细的ASP.NET AJAX客户端库感兴趣的话，可以参看我写的12 part webcast series。里面介绍了几乎ASP.NET 客户端类实现的所有方面。

第二个值得我们注意的地方是，AJAX类的命名空间和我们在第二篇里面创建的服务的命名空间是一致的。最后一件我想讨论的是，GetPatients操作(operation)被加到了AJAX类的原型(prototype)当中（在JavaScript当中，每一个对象都有一个对象原型。这个原型就是用来存放那些非实例特有的成员，例如方法，的正确地方）。你会注意到这里的操作的签名(signature)基本上是和我们服务操作的签名是一致的。不同的地方是这里多了调用成功或失败的回调函数，以及context参数。这些参数是必要的，因为回调函数是在异步模式下被调用的。换一种说法, 我们的服务操作被”AJAX化”了。现在调用我们的服务就变得很简单了：1) 创建一个代理类的实例。 2) 调用代理的GetPatients 方法。事实上，我们还有第三步和第四步要做的事情，我们还需要编写我们的回调方法。让我来通过扩充GetData的代码来给大家演示。

完成调用

在你刚开始创建你的代理实例的时候就会注意到的是，VS2008为代理类提供了IntelliSense支持。见下图:

下面是GetData的完整代码：

// This function calls the GetProductGrouping AJAX method,

// using the script proxy

function GetData()

{

var startIndex = ((currentPage) * pageSize);

var proxy = new shopping.services.CatalogService();

proxy.GetProductGrouping(startIndex, pageSize, ProductsReturnedEventHandler, ProductsFailedEventHandler, null);

}

我们曾经需要为实现正确的行为写上几十上百行代码，而不是这里的两行。当提到这点的时候，我是在特别针对那些已经不必再由我们自己去实现的那些串行化(serialize)和反串行化(deserialize)代码。如果你真的要自己去实现所有的代码的话，你必须写代码把你的客户端参数(以及方法信息，如果你用POST的话)串行化成例如JSON或者XML那样的格式。然后你需要在服务器端去写代码反串行化你的那些参数，调用服务，得到.NET类型的服务响应。接着你还需要将这些.NET类型再串行化回JSON或者XML格式（或者其他你选择的格式）并将他们以异步的方式传回客户端。最后，你还需要在客户端将这些数据流反串行化给JavaScript。 现在，.NET已经帮你打理好了这所有的一切。

在第二篇中，我讨论了ProductsReturnedEventHandler是如何简单的得到一个AJAX控件，设置两个属性的值（他们其中之一的值被设为服务调用响应的返回值），以及调用一个方法去做DOM插入。让我们在Visual Studio调试功能和WebDevHelper的帮助下来看一下往返发送的数据内容。第一个我想让大家看的是在做完所有串行化/反串行化以后传递给回调方法的参数。请注意传递给回调方法的JavaScript类型是我们在第二篇中详细讲述的.NET类型的近似表示。 就连.NET的类型名也通过”__type”被传递了。看下图：

下一个我要展示给大家的是真正的请求和响应（这里借助Nikhil的WebDevHelper工具）：

我们也可以看到请求和响应的内容：

控制如何曝露(Expose)服务

你在上面注意到，服务默认是以POST的方式曝露的。甚至大多数自由REST主义者(liberal RESTafarians)看到这个都会皱眉头。GET才是大多数人对于获取操作的实际选择。还有，你会注意到默认的数据表达格式（数据串行化方式）是JSON。但万一如果你并不想用JSON,而想用XML的某种形式那该怎么做呢？结论是，通过使用enableWebScript endpoint behavior你可以控制两样东西。通过webHttp endpoint behavior, 可以控制更多的东西。你将在以后的��章中读到这些内容。

为了控制操作的Http 动词(Verb)， 你可以用下面的一个或两个属性来修饰你的操作：

• [WebGet] – 将Http 动词设成GET
• [WebInvoke(Method=”…”)] – 将Http 动词设成GET以外的任意动词。不过，当使用了enableWebScript的时候，只有POST是被支持的。其他的动词只被webHttp endpoint behavior支持。

WebGet和WebInvoke都有一个ResponseFormat参数。你可以将它设成WebMessageFormat.Xml 或者WebMessageFormat.Json。你可以从下面的代码看到我如何设置这些选择。

[OperationContract]

[WebGet(ResponseFormat=WebMessageFormat.Xml)]

public ProductGroupingData GetProductGrouping(int startIndex, int pageSize)

为了演示这些设置的结果，我打开另一个的页面调用这个服务。下面是WebDevHelper里面的结果：

支持AJAX的REST服务的总结

在这两篇文章中， 我实现了一个支持AJAX的WCF服务和一个使用这个服务的AJAX客户端。那么，这个服务是否落脚在了REST领域中了呢？如果是的话，在哪里？我相信它满足了RESTFUL的标准。首先，它没有用到SOAP包，这无疑迈出了第一步。当我们比照不同的RESTfulness的不同标准的时候，我们发现我们的实现很明显落在了 LO REST这一边。考虑下面几点：

• 我们只用了两个Http 动词，GET 和POST。我们把PUT和DELETE都忽略了。在一个HI REST场景中，人们可以说，通过Http动词就足以理解调用的目的（GET用来获取，PUT用来插入或更新，DELETE用来删除，POST用来添加 – 或者一些类似的任务）。在我们的例子中，我们反复使用了POST。我们必须通过检查请求的内容才能够理解调用的目的。结论 -> LO
• 在URI可定位性(addressability)这方面，我们在GET中使用查询字符串。更进一步，我们的实现感觉上有点RPC的意味。结论-> LO
• 在表达格式这方面，我们可以选择任意二者之一。虽然JSON是标准，但他并不影响数据的含义，而只是一种语法罢了。并且，你当然也可以返回一种标准，在你的服务中接收XML的表示。结论-> 无法确定

请不要把我上面这段蠢话误解为在给这个服务打分。我不是这个意思，我喜欢这里的支持AJAX的实现。我只是想给你们一点东西去回味咀嚼它在REST领域中的定位。

在后面的文章中，我将会给大家展示一种更靠近于HI REST 一端的实现。

}
到这里，我们已经创建好了一个支持AJAX的服务。一个服务支持AJAX，就是说该服务可以非常容易地被一个 AJAX 客户端调用。接下来的 WCF中的REST架构 三，我就讨论如何在客户端调用服务.

WCF中的 REST架构一（REST 概述）

不同的人似乎对REST有不同的定义，有些定义是非常严格的，而有些则是比较自由的。我倾向于认为REST架构存在于一个连续的范围里， 如图所示：

我们可以认为REST背后隐含的基本理念如下：

· 越简单越好

· Web一直是非常成功的。

· Web是很简单的。

· Web设计要遵循一些指导性原则，而这些原则在过去很长一段时间内都是可靠的。

· Web 服务的设计要以 Web的方式。

尽管不同的人对 REST有不同的定义，但可以肯定的是存在一些特征来影响一个服务是否是RESTful的，或者它能不能被认为是RESTful, 或者它能否落在上面这个连续范围内的某个位置。这里列出一些（并不是全部）特征：

· 对HTTP 方法(GET,PUT,POST,DELETE是主要的HTTP方法)的合理使用——HI-REST端倾向于对具体方法用于具体的情景进行严格的规定。例如一个HI-REST的实现中使用GET方法获取，DELETE方法用来删除，PUT方法用来插入或者更新，而POST方法则用来附加。而LO-REST的解决方案则可能使用POST方法做插入，更新，删除和附加操作。

· 对数据表现形式的选择——HI-REST解决方案倾向于选择标准的数据表现形式，而一些LO-REST解决方案则认为POX也是一个不错的选择。

· 对良好构造的URI的使用——HI-REST解决方案倾向于使用描述性的URI而一般情况下不使用查询字符串，而我们在一些LO-REST解决方案中可以看到对查询字符串的使用。

· 其他：有效负荷中包含指向相关信息的链接，使用合适的HTTP 响应代码。

我没有在什么是REST的基础上给出一个严格的定义，原因并不是我觉得这不重要。原因是，从WCF的角度，一个专门的定义无关紧要。WCF支持范围两端的REST架构（HI-REST和LO-REST）。事实上，在下一篇文章中，我将建立一个LO-REST的实现，同时在之后的文章中，我将演示HI-REST端的实现。

如果上面这些对你来说都没有什么意义，也没有关系，下面的文章将提供具体的实例。