Rest的作者认为计算机发展到现在，最大的成就不是企业应用，而是web，是漫漫无边的互联网web世界。Web能有这么大的成就，它值得我们研究。所以Rest的作者仔细研究了Web，按照Web的世界一些关键特性，提出了我们在实现企业应用的时候应该遵循的一种风格，就是Restful。

Rest风格的API可以给我们很多好处，比如：简洁，统一，性能，可扩展性等等。可惜的是，在实现Rest的时候，总有一些Rest的关键特性没有实现，比如，无状态性，这在我做过的两个项目和我知道的另外一个项目都存在。事实上要实现无状态性在java里不是那么容易，因为那意味着要把servlet的session抛弃了。除此之外，Rest的一些其他特性在各个项目中实现的也是各有不同。

接下来，我会列出一些我认为的，要实现Rest风格API的关键步骤：

1. 所有东西都是资源（Resource）

所有要给API操作的对象都只能是资源。不管实际上存在的，还是抽象上的。所有资源都会有一个不变的标识（ID），对资源的任何API操作都不应该改变资源的标识。资源和其他资源会有关系，资源与资源的关系通过资源的标识来引用。对资源的操作都应该是完整的，比如获取资源拿到的应该是一个完整的资源对象（根据企业引用特点有些例外，后面会提到）。

事实上，上面的这些完完全全是按照互联网的特性提出来的。互联网中，一个URL就是一个资源；资源的内容就是HTML页面；不管怎么改HTML内容，URL都不会改变；资源之间通过HTML里的连接联系起来；每次获取的时候，获取到的都是完整的HTML内容。

假设有一个博客系统，那么其中的资源可以包括：博主，每个博主都是一个资源；博客，每篇博客都是一个资源，博客和博主之间有联系，通过ID联系起来；每篇博客都会有回复，回复也算是资源，但是它是隶属于博客的，可以认为回复是博客的子资源（你也可以认为博客是博主的子资源，怎么抽象取决于具体的应用，这里不讨论）。

这步通常不难实现，因为这和ORM中的对象概念是类似的，实现上，，如果用了Hibernate之类的框架，改动也应该很小。

2. 规范对资源的操作，最好只包括CRUD

CRUD指创建（Create），读取（Read）， 更新（Update），删除（Delete）

通常对资源的操作只包含CRUD是不可能的，CRUD里甚至连查找的操作的都没有。但这不妨碍我们对Rest的理解，Rest提出的要求是，对资源的操作都应该是统一的，不管是操作哪种类型的资源，API都应该是一致的。这样当调用API的客户端知道某种资源的时候，它不需要去学习对这个资源该怎么操作，因为对所有资源的操作都是一致的，它们都应该支持CRUD操作，以及一些其他操作，比如list（用来查找，或者列出所有资源）， merge（部分更新资源，这应该是唯一的不操作资源所有内容的API）。

这和Web也是一样的，HTTP里只有GET，PUT，POST，HEAD等等几个统一的请求（参考：）。

要实现简单的几个操作不难，难在这几个简单操作没法支撑整个系统的需求。但是想想吧，互联网也够复杂了吧，还是不是成功了，而且鱼和熊掌不可兼得。有时候服务器端也不一定要实现所有东西，可以把一些逻辑交给客户端去做。比如显示，Rest里显示是完全交给客户端去处理的，服务器只管数据的存储，不管客户端是网页，还是一个手机应用程序，还是另外一个企业应用。各种各样的客户端进来，他们会有各种各样的需求，服务器端不可能一一满足，只能客户端使用统一的API去组合，实现自己的需求。

3. 规范URL的使用

好了，对资源的操作统一了，但是客户端还是要知道怎么触发对资源的某个具体的操作。Rest用URL的规范来保证这种统一性。

创建并保存一个博客：

[plain] view plaincopy

 

POST /blog/save  

这个请求需要返回博客的保存后的结果，其中包括博客的标识（ID）。 获取一个已经保存的博客，并更新它：

[plain] view plaincopy

 

GET /blog/get/345  

//更新它  

POST /blog/update/345  

这个博客的标识是345。获取博客的某个回复：

[plain] view plaincopy

 

GET /blog/get/345/reply/456  

对待子资源，通常的做法就是和这个例子一样，是一级一级的往下找。我们还可以有其他方法，比如remove用来删除，merge用来部分更新，list用来查找。

有三种方式可以将参数传给API操作：

第一种是通过URL的地址传递，如前面的例子中把标识放在URL里；

第二种是通过URL的参数，比如，对于一个查找请求，可以把查找的过滤条件放在参数里：

[plain] view plaincopy