RESTful这个东西大家都谈的很多了。然而这里面还是有些东西可以深挖。
经常面试的时候，问什么是RESTful，很多人都大谈特谈怎么建立一套RESTful的API，这很好，但是这并不是RESTful的核心，正如RESTful这个名字一样，其核心是服务端的stateless概念。
第一个根本问题，如何理解stateless。这个问题2年前在我的微信里已经讨论过了，EMC的小伙伴应该都看过了。stateless的好处是明显的，把state推给客户端，这样服务端很容易做负载平衡。但是，这里有一个貌似stateless无法处理的东西，异步调用。假设客户端调用服务端的一个service，这个service是一个异步调用，意思就是客户端调用后服务端就直接返回了一个token，之后这个service实际上是在服务端做job，客户端以后需要用这个token去查询这个service在服务端有没有完成。那么这个时候，服务端就没法做到stateless了，因为服务端一旦没有保留任何状态的话，那么客户端查询有没有完成的时候服务端又怎么能找到这个对应的job呢？所以这个token和job的对应关系这个state，还有job运行本身的一些state，是一定需要的，那么这样就不是stateless了。
以上这个案例，看似很有道理，然而，RESTful要自圆其说，其实也是有办法的，这主要取决于看concept的角度不同。RESTful里还有另一个concept叫resource，如果认为state是存储在服务端内存中的话，那么只要我把state给serialize到db或者其他外部存储，而这个外部存储整个cluster都能访问所以不影响负载平衡，那么这时我就可以认为这个state实际已经变成了一个resource，客户端的查询其实是针对一个resource的查询，那么这就是标准的RESTful。
所以，state和resource的概念其实是RESTful整个concept里面一个并不互斥的东西。这也是RESTful本身没有也没有办法充分定义的模糊部分。
第二个根本问题，服务端要求stateless，但是这与OO的concept有根本性的冲突。OO的concept要求封装，封装的是对象所操作的数据，但是这些数据的封装到底意味着什么呢？其实在服务端我可以认为就是封装了服务端的state。现在服务端要求stateless，这就意味着我的OO最强大的能力已经在stateless的要求下毫无用武之地了，如果写一个完美的stateless服务端，那么服务端的class就只能是一个空壳，class的member一个都没有，class的method可以全部写成static也没有问题。
对比一下基于RPC的service call，在RPC结构下，一个class的method是不是remote call被完全的隐藏了，这和OO的整个concept完全兼容，可以充分的发挥OO架构的实力，对于复杂系统可以基于OO的架构模式对客户端和服务端通盘考虑来设计一个比较完美的OO架构的方案。然而现在对于stateless的RESTful服务端，OO只剩了一个空壳，这意味着对于复杂的系统实现一个stateless的RESTful服务端架构难度倍增，而且stateless的服务端代码写起来因为没有OO也会变的更难写。
大家都在说RESTful如何如何好，但是我估计很少有人能深入思考到上面的问题，那么对于stateless和OO的矛盾，是不是就没解了呢？然而也并不是。既然实现一个stateless的复杂系统很困难，那么我们永远都可以分而治之啊，实现一个stateless的简单系统并不困难，我只要把一个大的复杂系统分解成一堆小的简单系统来设计就行了，所以我认为，这是最终推导出microservice的一个有效思路。当然我还是后知后觉的，这个问题当我在IBM做第一个RESTful项目的时候就开始思考，困扰了我很多年，现在在思考microservice的时候终于能反向推出了一条思路，把这几个关系联系了起来。
另外一个角度，OO只不过是一种编程方法，死抱OO不放也没有任何意义，stateless虽然不适合OO，但看上去貌似和functional programming很合适呢，同样是没有member variable，同样是可以轻松解决thread safe。或许这也是现在functional programming逐渐流行开来的一个原因之一。
当然，还有一些高级话题比如怎么定义JSON的protocol，所谓的hypermedia的concept这些就推荐这本了：
以上！
网友评论