REST手记(一)：对URI隧道技术以及CRUD操作的理解

　　近来看了Jim Webber等REST实战，有一些体会，因此对一些概念做个简要的整理。以下是个人认识与理解，如有偏差，望指正。

• 1、URI隧道技术。

　　通过URI来进行跨越系统边界转移信息的一种方式。它是通过将信息编码到URI中。如：http://www.taobao.com/PlaceOrder?size={xx}&type={xx}&color={xx}这是一种有效的方法。因为无论在Server端还是Client端，它都容易被理解。但是在一般情况下，URI隧道技术并非是Web友好的。因为它没有描述对资源进行操作的方式、以及操作资源时使用的元数据。如果有消费者使用Get操作来操作以上URI而产生资源，那么就完全违背了Web的架构原则。

• 2、CRUD的WebService。

　　在说到CRUD之前，先说说幂等。
　　幂等是数学上的概念。无论操作操作多少次，这次操作产生的结果都是一样的。比如：数学中的计算绝对值。

　　2.1 C:Create。
　　Create 资源通过HTTP POST动作创建。POST在HTTP协议中就被设计为不安全、不幂等。为什么说它不安全？因为消费者将信息POST到服务中，服务就需要为客户端创建资源。这样就有可能改变服务端资源的多少、组织形式等等。为什么说它不幂等呢？
因为根据HTTP协议的规范，POST信息到服务端后，服务端就需要创建资源。一次POST就创建一个新的资源，即使消费者每次提交的信息完全一致。

　　2.2  R：Read。
　　Read读取资源。通过HTTP GET操作获取。即安全又幂等。因为它多次获取资源，但是不会对资源的状态进行操作，所以说它是安全的。
　　也许有人会说，如博客园获取48小时阅读排行，那按照幂等的说法就应该每次都获取一样的信息，而不会有更新出现。是的，你这种说法没错。如果每次获取资源都一样那就应该不会更新。这里所说的幂等指的是这类资源的性质是一致的。而不是说资源的表述每次都应该一样。

　　2.3 U：Update。
　　PUT 操作进行资源的更新。它幂等但是不安全。幂等表现在它对资源的多次操作，最终在服务端，按照HTTP标准，应该用客户端上传过来的信息完全替换掉服务端相应的资源。因为这可能导致服务端资源状态发生变更，所以它不安全。
　　PUT 操作完成以后，返回给客户端一个200相应消息的详细描述或者204 no content 信息。但后者由于相应信息少，因此效率更高。当然在最新的IETF Internet标准中新增了PATCH动词，但是PATCH是对部分资源发送补丁信息，服务端针对这些信息对资源进行部分更新。

　　2.4 D：DELETE.
　　DELETE删除资源。与Update操作一样，幂等但是不安全。注意：这里的DELETE不一定是真要是服务端删除某一资源，只是表明REST某一客户端对这一资源已经不再关心，但是这些资源可能会被其他客户端所用到。

• 3、校正资源状态。

　　在分布式系统应用中，经常出现多个消费者与一个资源交互的应用场景。这样就有可能导致一个问题的发生。比如：一个用户对资源进行操作而改变了它的状态，而另一消费者没有通过Get获取到最新状态，同样去操作这一资源就不会得到想要的结果。
　　HTTP提供了一种简单但是强大的机制来解决这个问题。那就是通过实体标签（Entity Tag）与条件请求头(Conditional Request Header)If-Match或If-None-Match的形式，对所请求的资源进行校正。一个实体标签就是一个不透明的令牌，使服务端与资源关联起来，以便在资源的生命周期中唯一。可以通过Hash算法来指定ETag值。
　　If-Match或If-None-Match很好理解，如果匹配则如何，如果不匹配又如何处理。
　　通常If-Match:"*",来指明资源存在，If-None-Match:"*"则指明资源不存在。
　　篇幅有限，这节就这么多了。希望对你理解REST有些帮助。
　　下一节将介绍：超媒体服务、以及相关的一些概念知识点。