背景

项目的背景是基于一个开发中的 Web Application，提供一套Web API出来，以供移动平台的客户端调用，从而在移动平台上实现大部分那个web application所提供的功能。

而这个博客的背景就是打算把这个开发过程大致记录下来，主要描述下碰到些什么问题，都想过怎么解决，以及最终采用了哪种方式解决的。

Why RESTful?

RESTful的好处就不说了，google之。对于我来说，决定使用RESTful架构，一个主要的原因是RESTful的api看起来简洁，很符合时下流行的审美观。通过每个api的url都能猜个大概这个api是干嘛的了，也方便开发人员调用。也是因为简单的原因，在接口的参数传递上，也选择了JSON,没有用XML。

WebAPI

一开始用WCF实现了一个hello world的RESTful WCF api，发现这个api暴露出来的地址不是很舒服，有一个.svc在里面，感觉很不爽。虽然可以用IIS7的url rewrite去掉地址中的.svc，但是懒筋一动，没有去看IIS的URL rewrite。

转而投向ASP.NET MVC，用MVC实现了一个restful的hello world api。现在看如果用MVC的话，需要在global里面注册一堆的routers，导致global.asax.cs也不够简洁，以后再想办法把。

经过一番Google，在著名的http://wcf.codeplex.com/找到了一个叫WCF Web API的东西，它还自带一个Test Client，而且这个测试客户端还有智能感知，用起来挺方便，不用每次再用Fiddler写请求了。于是决定就用它。

资源

Here comes the first part!工具似乎齐全了，就开始准备制定api的接口。RESTful的规则和含义理解起来很容易，但是真正想按照规则实现一套架构，似乎又不是那么容易下手。套用一个放在这里并不那么不确切的名言：Less is more。结果越简单，实现的过程越需要花功夫。

第一个问题就是制定资源。资源到底是什么？那些系统中能找到名词的就可以算是资源，比如一个订单。但是那些系统的动作呢？比如最基本的，讨论的最多的登录动作。可登录是一个动作，怎么映射到一个资源呢？还是说登录是一个对用户这个资源的一种动作？似乎两种说法都可以说的过去。我打算把登录和注销单独理解为一种资源，比如说就叫”login”用户凭据。那么登录就是post一个Login资源，注销就是delete一个login资源。想通了这一点，就找到了一个基本的准则。就是但凡是一个动作，那这个动作肯定是针对某一个object的，那么就给这个object起一个名字，把它认为是一种资源。

资源问题初步解决了，接下来再考虑考虑别的东西，比如安全。

这个下次再说。