不要盲目遵循 RESTFUL 接口规范

  最近在优化公司的接口规范，原有的规范文档里面规定服务端要严格遵循RESTFUL风格的接口，但是实际执行下来很多开发人员根本没有按照RESTFUL接口规范来，当然这个里面很多是执行层面问题，但是也有另外一个问题：很多业务接口根本不适应RESTFUL规范。

  这两天我也翻阅了很多文章，大部分文章在讲RESTFUL规范的时候都只是停留在理论阶段，只是说到RESTFUL标准是什么（URL名词化、用GET/POST/PUT/DELETE替代URL中动作、用HTTP状态码作为返回的CODE等），很少有说到在项目中如何解决一些应用RESTFUL的实际问题，比如：登入、登出、批量增加、复杂查询、导入导出这些接口如何定义。一般实际项目中都会有很多这种不同于CRUD的API接口，这些API接口用RESTFUL标准去强行适配是不合适的。

  结合网上的一些文章，我总结下自己对RESTFUL引用的一些个人观点：

1、不要盲目跪舔RESTFUL标准，RESTFUL标准并不能适用所有情况。

2、不忙从不是否定，RESTFUL在很多时候是适用的，所以在很多情况下还是要遵循RESTFUL的一些标准，比如Openapi对外的接口要求上就可以尽量遵循RESTFUL标准，保证一致性，但是对内就没必要完全遵循了。

3、针对不适应的情况，可以考虑采用JSON-RPC标准，也就是“post /命名空间/资源/动作”这种方式，这种也是我在很多项目上看到的命名规则，包括很多大厂都是这种命名方式。

 

所以任何规范和架构设计都要结合实际情况来，不能盲从。