要记住的第一件事是REST服务应该是无状态的，这与SOAP/RPC类型的服务接口有很大的不同。使用REST方法需要您重新考虑希望客户端如何与服务交互，将交互分解为清晰简洁的方法调用。
休息

• 轻量级消息，开销很小（除了XML本身）
• 结果易于读取，可轻松使用Web浏览器进行测试
• 易于实施

• 松动器接口，松动类型检查
  SOAP协议

• 更严格，合同定义严格
• 大量可用的开发工具。
  浏览WCF MSDN文档，WCF SOAP支持从一开始就集成了，而REST支持是最近添加的功能。我自己很难找到REST服务的身份验证/安全性文档，因为大多数文档都是针对SOAP的。
  客户端生成工具：我还没有遇到过任何针对REST服务的协议，因为REST不像SOAP那样定义服务契约。WADL尝试为REST服务定义服务契约。http://en.wikipedia.org/wiki/Web_Application_Description_Languagehttp://wadl.codeplex.com/
  我对阅读更多关于身份验证和安全性的回复很感兴趣，因为我自己也在研究这一问题。

这是一个很好的WCF REST Web服务的起点：
REST / SOAP endpoints for a WCF service
(BTW：Stackoverflow有很好的REST类型的url。）你可以测试一个REST服务只需要一个网页浏览器（去到url，并获得XML或JSON）。Fiddler也是一个很好的工具，和FireFox的FireBug插件。我通常做一个瘦的服务接口项目和一个单独的（单元测试）逻辑项目。
对于认证，我会先生成一个GUID和一个时间戳，然后基于这些生成一个哈希值（.NET支持SHA 256和SHA 512）。GUID可以存储到服务器（数据库表），以Map到一些具体的数字ID。然后，您可以有一个如下的休息URL：

/myobject/1?timestamp=20100802201000&hash=4DR7HGJPRE54Y

并且在开发环境中禁用哈希和时间戳检查（例如使用AOP）。使用时间戳，我会检查时间戳在15分钟前和15分钟后之间（=应该足以防止攻击）。
您的服务对公众/互联网可见吗？您的客户端是jQuery还是Silverlight客户端？那么您仍然有一个问题：您不希望在客户端软件代码中包含密钥。
因此，您需要在服务器端生成散列，并生成某种cookie来存储客户端会话。（例如，可以使用不同配置文件的文件夹中的单独登录页面/应用程序来完成。）我记得this book确实有关于此主题的内容：
如果希望在使用WCF时启用HttpContext，需要在<system.serviceModel>下设置<serviceHostingEnvironment aspNetCompatibilityEnabled="true">，这样就可以从HttpContext.Current.User.Identity.Name查看当前用户身份。
但是，如果您想创建纯REST服务，则不使用cookie，而是为每个调用使用HTTP基本身份验证和SSL/TLS。
我认为只使用LINQ 2Xml或jQuery制作客户端很容易，所以可能不需要客户端生成。
或者您也可以同时拥有SOAP和REST接口，并使用服务引用来创建客户端。

需要记住的一件事是，您可以将REST视为一种哲学（所有内容都应该可以通过干净的URL访问，而不附加隐藏字符串），也可以将其视为一种教条（您必须使用PUT和DELETE，即使这意味着很大的困难）。
重点在于简化--比如使用简单的数据类型作为参数，而不是结构化的堆积，也不是因为多余的原因而使界面过于复杂（比如在url中拖巨大的页面"title"），也不是使用众所周知的事实上的标准。
所以，你可以只使用GET来设计完美的RESTful界面，并保留Web浏览器的可用性和可测试性。你也可以使用任何标准的身份验证方法，或者根据你的实际目标受众使用其中的几种方法来实现冗余。如果你正在制作一个应用程序，并使用标准化的凭据和令牌在企业网络上运行，你可以继续使用它。如果你正在做一些非常普通的访问，你可以使用GET参数和/或cookie的组合-保持你的URL为99.99%的用户干净。
您甚至可以同时提供JSON和XML（例如GoogleMap），并且仍然是RESTfull，但您不能执行全面的SOAP（复杂的输入类型等）。您可以执行有限的SOAP-请求的简单类型，总是可以表达为GET参数，人们仍然使用WSDL作为文档。
希望这描绘了一幅足够灵活的画面--超越任何严格教条的思维方式。