RESTful广泛运用于互联网服务，而在企业应用中，大部分场景仍然是RPC服务，这是由于企业应用的业务复杂性造成的。但是基于SOAP的RPC服务也存在很多的弊端，比如服务异步处理比较麻烦，大部分RPC服务仍然是阻塞性质的，即使在.net 4.5的今天，异步编程已经通过asyn/await极大简化的情况下。其中的原因也挺复杂的，有兴趣了解的可参考以下文章：http://blogs.msdn.com/b/pfxteam/archive/2012/03/24/10287244.aspx
简单得将以前的RPC服务进行异步封装是没有必要的。
因此，在适当场合可以考虑提供REST服务，当然REST服务与RPC服务的区别，优劣并不是仅体现在这方面，还有其它诸如跨平台性、可扩展性等方面，因为这两者的协议是完全不一样的，REST毕竟是基于HTTP协议，几乎适用于当前所有平台。
其实microsoft早在.net framework 3.5时期，就已经提供了REST的实现，当时是基于WCF技术，通过对操作增加WebGetAttribute,WebInvokeAttribute来实现GET,POST操作。不过由于其还是基于WCF框架，通过其管道来进行服务调用，还需要配置对应的webHttpBinding，因此个人感觉在.net 3.5时期，REST并未得到广泛应用，当然这也可能是由于我并未从事互联网行业的缘故。
到了.net framework 4时期，microsoft提供了web api这一套框架，用于支持REST服务的开发，最近段时间使用了下，觉得还是挺方便地，对HTTP协议提供了很好的支持，包括可以自定义Request,Response的Header,Content等等，目前我需要的功能，这套框架都能很好地提供支持。并且，服务能够直接通过浏览器，如Chrome,FireDebug等等调试，同时，与WcfTestClient类似，我们也可以用Fiddler之类的调试工具进行很方便的调试。
使用web api框架是很简单的，直接参照ASP.NET的入门文档（http://www.asp.net/web-api/overview/getting-started-with-aspnet-web-api/tutorial-your-first-web-api），即可很快地搭建起来一个架子，并成功地提供REST服务，在这里我就不重复贴出实现代码了，其关键点如下：
1：通过NuGet获取Microsoft.AspNet.WebApi.SelfHost包，因为我一般使用自宿主模式，很少寄宿在IIS；
2：对需要提供服务的资源(resource)建立对应的controller，在REST中，一切的核心就是resource，围绕resource提供GET,POST,PUT,DELETE等操作，这点与RPC有很大区别，思维模式的转变很大;
3：提供宿主，运行即可，ASP.NET的入门文档中，宿主是Console Application，实际运行环境中，我一般寄宿在Windows service中，其实是非常类似的。
做完以上三部，咱们的REST服务就已经向外提供HTTP服务了。注意这里第3点有个需要注意的小细节，必须以管理员权限运行宿主进程，否则无法监听URL端口。
但正如上文第2点中所说，REST真正的难点，个人感觉并不在技术实现上，其实是一种思维模式的彻底转变，由长久以来RPC服务中业务活动流程为中心的服务设计思想，转变为资源为中心的设计思想，在这样的思维模式下去对我们实际场景中的各种服务进行与以往相比颠覆性的重新设计，才是REST真正的难点所在。
这篇随笔先写写这些，算是个基础入门，架子打起来算是勉强摸了下门槛，之后的工作才是任重道远。