RESTful接口设计原则/最佳实践（学习笔记）

RESTful接口设计原则/最佳实践（学习笔记）

原文地址：http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api

一、RESTful接口建议统一使用复数，而不是单数
二、不建议使用HATEOAS
三、在大多数的教案中，都推荐使用Accept Header来指明是xml仍是son，而做者建议直接在url中增长.json或者.xml
四、使用snake_case命名风格来给RESTful URL命名，而不是camelCase风格
五、为了保证接口的可读性和友好性，不建议本身将json中多余的空白去除，而是提供格式化良好的信息以知足用户调试的需求，启用gzip一样可以减小到由于空白等问题而引发的数据大小问题。
六、当一个Resource被查询的时候，可能有一些相关的资源须要被关联出来，则能够在参数中携带embed (或者expand），而后能够把相关的资源展开（好比原来描述一个id，如今把id对应的具体对象也查询出来）。
七、原文中一些其它的观点（很是多），由于比较常见/不太容易简单地表述，因此就没有列出来了，最好阅读原文。

 

我的理解：（非原文观点）

一、关于embed（或者expand）参数而言，若是是用文档式/KeyValue式的NoSQL数据库，则彷佛根本不须要，它们自己就把对象聚合在了一块儿。
二、关于缓存，若是要在RESTful中用好ETag、Last-Modified，假设RESTful后台是关系型数据库，那么如何标识一个资源的版本/修改时间呢？这个实际上是很是难的，由于对于一个存在多表联查的对象而言，你能够保证单个表中的信息未更改，你不能保证关联表中的信息未更改，并且当你再增长fields（参考原文）限定的时候，你说在此范围以外的变化算变化仍是不算变化？可是用文档式/KeyValue式的NoSQL数据库的话，感受在大部分场景上就容易得多，由于一般一个Key对应的结果，是固定的，不存在多表联查的问题，那么版本号这件事就能够是一个特殊值被“设计”在对象中。