谈谈 Restful 风格

前言

当我们开发一个服务的时候，API接口如何设计便是个麻烦事。不同的开发者可能有不同的设计风格。
但我们都很明确的是，API本质上是一个信息传递的协议，传递指令和数据。HTTP是目前互联网上使用最多的应用协议，加上相关的框架十分齐全，若不是用于特殊场景，HTTP协议基本是首选。

RPC式API

对于一般的业务，较为简单的设计就是URL对应函数，JSON或Param为其参数，就可以实现一套API的设计。比如

POST example.x64/api/v1/task/create
GET example.x64/api/v1/task/list

看上去也非常简单。至于什么时候用POST，什么时候用GET，稍微了解HTTP的就知道，
1. GET通常用于查询，可被一些代理缓存加速。
2. POST用于写操作，可传递复杂参数，不会被缓存，也可避免跨域攻击。

什么是Restful风格

REST（英文：Representational State Transfer，简称REST）描述了一个架构样式的网络系统，比如web应用程序。它首次出现在2000年Roy Fielding的博士论文中，Roy Fielding是HTTP规范的主要编写者之一。
以用户的增删改查为例。

GET     example.x64/user/list  #获取所有用户信息
POST    example.x64/user       #创建用户信息
PUT     example.x64/user/sean  #更新用户信息
GET     example.x64/user/sean  #获取资源标识为sean的用户信息
DELETE  example.x64/user/sean  #删除资源标识为sean的用户信息

可以看出，在资源管理方面，Restful很好的利用了HTTP。但随之而来的问题是，这对我们有什么好处了吗？

为什么选择Restful风格呢

这是标准

似乎有不少工程师都说自己很懂Restful风格，这是业内标准，但我们发现大家的Restful风格或多或少都有一些方言存在，不同的人理解的Restful并不一定一样。
而且，对于一般的HTTP开发者来说，常用的也就是POST和GET,像PUT,DELETE估计基本碰不到。这显然提高了使用者的难度，也等同于增加了用人成本。

更容易理解

有的人说，Restful大家容易理解。但实际上面向过程肯定比面向对象容易理解。大家都是先学习C再学C++的。
此外，对于API的使用者而言，SDK才是最好用的，比如阿里云等云平台，都有配套的SDK,有这玩意谁关心是不是用Restful风格呢，哪怕是用TCP的都无所谓。

更好用

而在编码方面，显然Restful相比简单的RPC式调用要写更多的代码。因为原本URL是不携带参数的，而现在URL携带了参数，这意味着开发者需要处理更多的东西。
而且可以看出，API的使用者和开发者的代码量都会增加。这看上去并没有为开发者提供好处，反而是添麻烦。

更好的抽象

我们可以看出Restful风格适用于资源的抽象，但很多东西却并不是都能做这类面向对象的抽象。比如我想检查一下这个资源是否正常。于是，破坏Restful风格的实现就出现了。

GET  example.x64/user/sean/check

这就好比，我们需要买6元的东西，对方没有零钱，我们手里只有5元和2元的。那通常你只能亏1元了。
过度的抽象便是如此，高层次的抽象，覆盖面会有所缺失。低层次的抽象虽然更费事，但通用性更强。
比如像S3这类操作资源的API使用Restful可谓是物尽其用。但如果是云平台这种，存在大量操作属性API的话，使用Restful只会非常奇怪。所以我们看阿里云是将OpenAPI分成了RPC和ROA两种机制。这不失为一种折中的办法。

Restful风格的来历

从Restful创始人的身份,Roy Thomas Fielding,我们就可以指导，Restful风格其实是对HTTP的一种实践。Roy Thomas Fielding 是美国计算机科学家，是HTTP规范的主要作者之一。
简单说，Restful是让你充分利用HTTP，同时也让你的程序和HTTP绑定在一起。
这就好比马云告诉你，开商场可以去天猫开。大家都没错，但如果使用者没有真的理解它，就容易作出错误的选择。

总结

这个世界没有银弹，用一个技术的时候，我们应该要考虑它的两面性，要确定我们真的了解它，并且能把控它，否则，不使用它是最好的选择。
流行的东西，不一定都是好的，比如流行性感冒，还是那句话，没有最好的，只有最适合的。
刚入行时，总想着用更新的技术，现在才明白，用靠谱合适的技术才是正确的选择。