InfoQ上有一篇《深入浅出REST》的文章：http://www.infoq.com/cn/articles/rest-introduction

文章中的主要观点包括了：

 A. 为所有“事物”定义ID
 B. 将所有事物链接在一起
 C. 使用标准方法
 D. 资源多重表述
 E. 无状态通信

读完后有下列疑问：

A. 观点1中这个“ID”如何定义？

文章中提到了使用URI作为所有“事物(资源)” 的唯一ID，于是为了这样一个疑问：为什么不能用URL，而用URI呢？网上对URI和URL的区别并没有一个明确的说服，我个人的理解是这样的：

URI是资源标识符，而URL是资源定位器。假设我们对所有的资源都进行统一标识(注意是全局唯一标识)，有一个资源的标记是4321，那么这个4321是URI。而如何获取到这个4321资源呢？URI并没有说明。于是我们可以同HTTP协议，或者FTP协议来获取，这种依赖于特定通讯协议的获取方式就是URL了。

但是不管是URI还是URL，只要指向同一个资源，最终都是通过唯一的这个标识(URI)来区分资源的。

不知道这个理解是否正确？

B. 要为那些“事物”定义ID？

文章中提到了我们不单为一个单一的资源定义ID，我们也可以为资源的集合定义ID。于是就有了这样的疑问：

对于一些集合范围比较明确的资源，比如blog的按年月日分类，我们可以简单地使用诸如这样的URL：http://xxx.com/archive/2010/06/24/324348.html 来表示REST风格的资源，但是如果这个集合的范围是模糊的，或者是靠某些条件表达式的执行结果来限制的，比如说所有符合条件1的文章集合。那么对于这种模式的资源，REST又如何来表示呢？

进一步地引申到实现问题？假如为这么多事物引入ID，那么会不会导致我们的存储结构暴增？在上面这篇文章中也提到了这样的观点：

C. 使用链接指向任何可以标识的事物

这一点上，我看不出REST和传统的的Web概念有什么明显区别的地方？也许是我的理解不够

D. “标准方法”是否够用？

从文章中可以看出，REST依靠HTTP协议的动词(get/put/delete)来描述对资源的操作，于是在我们的应用端有了很多抽象的标准方法：getAll, delete, getById....。问题是仅仅依靠这些标准方法够吗？

传统的WEB请求是通过在请求中附着参数信息，如XXX.jsp?参数1&参数2，如果我们采用了REST方式的URI描述，对于一些复杂的请求描述，会不会导致描述困难？而且对应的服务器端方法如何定义？毕竟现在很多的交互网站都有大量的自定义查询，仅靠几个简单的CRUD方法定义显然不能满足，那么REST是如何解决的呢？

E. 无状态通信如何实现

这是最令我困惑的一个地方。原文翻译如下：

无状态通信是我要讲到的最后一个原则。首先，需要着重强调的是，虽然REST包含无状态性（statelessness）的观念，但这并不是说暴露功能的应用不能有状态——
事实上，在大部分情况下这会导致整个做法没有任何用处。REST要求状态要么被放入资源状态中，要么保存在客户端上。或者换句话说，服务器端不能保持除了单次请求之外的，任何与其通信的客户端的通信状态。这样做的最直接的理由就是可伸缩性—— 如果服务器需要保持客户端状态，那么大量的客户端交互会严重影响服务器的内存可用空间（footprint）。（注意，要做到无状态通信往往需要需要一些重新设计——不能简单地将一些session状态绑缚在URI上，然后就宣称这个应用是RESTful。）

但除此以外，其它方面可能显得更为重要：无状态约束使服务器的变化对客户端是不可见的，因为在两次连续的请求中，客户端并不依赖于同一台服务器。一个客户端从某台服务器上收到一份包含链接的文档，当它要做一些处理时，这台服务器宕掉了，可能是硬盘坏掉而被拿去修理，可能是软件需要升级重启——如果这个客户端访问了从这台服务器接收的链接，它不会察觉到后台的服务器已经改变了。