👏摘自《趣谈网络协议》（作者：刘超）的RESTful协议---音频版🎧和RESTful协议---PDF版📚
RESTful全称是Representational State Transfer，即表述性状态转移。它不仅仅是一种规定的标准，其实也是一种设计风格。它关注的是状态的问题。
什么是状态呢？这里举几个例子，例如，我浏览到哪个目录了，我看到第几页了，我要买个东西，需要扣减一下库存，这些都是状态。
在RPC场景下，是由服务端来维护状态，这种模式原来没有问题，是因为客户端和服务端之间的比例没有失衡。因为一般不会同时有太多的客户端同时连上来，所以NFS还能把每个客户端的状态都记住。
但是互联网场景下，客户端和服务端就彻底失衡了。你可以想象“双十一”，多少人同时来购物，作为服务端，它能记得过来吗？那服务端索性就要想了，既然这么多客户端，那大家就分分工吧。服务端就只记录资源的状态，例如文件的状态，报表的状态，库存的状态，而客户端自己维护自己的状态。比如，你访问到哪个目录了啊，报表查看到哪一页了啊，等等。这就是服务端的无状态化。
所谓的无状态，其实是服务端维护资源的状态，客户端维护会话的状态。对于服务端来讲，只有资源的状态改变了，客户端才调用POST、PUT、DELETE方法来找我；如果资源的状态没变，只是客户端的状态变了，就不用告诉我了，对于我来说都是统一的GET。虽然这只改进了GET，但是已经带来了很大的进步。因为对于互联网应用，大多数是读多写少的。而且只要服务端的资源状态不变，就给了我们缓存的可能。
按照这种思路，对于API的设计，就慢慢变成了以资源为核心，而非以过程为核心。也就是说，客户端只要告诉服务端你想让资源状态最终变成什么样就可以了，而不用告诉我过程，不用告诉我动作。
RESTful其实没这么复杂，也没给客户提供很多的可能性，能够发出的动作一般只有CRUD，即基本满足增、删、改、查的需求，比如增是POST，删是DELETE，改是PUT，查是GET，也就是对于状态的改变。
网友评论