DRF系列总结一：DRF是啥？为啥子要用？

目前组内很多项目都在用Django REST framework（简称DRF）来构建Restful WebApi，并推广到了许多实习生同学和外部服务商的开发同学使用。对于刚接触DRF的同学，都觉得有点儿懵，搞不懂为什么要用，怎么用才是最好的，于是我想把项目中对DRF的使用经验总结出几篇文章，希望能帮到后面的开发同学。

首先，假设阅读这篇文章的同学使用过Django或开发过蓝鲸应用，然后，我们先来简单了解下Django REST framework（DRF）：

一、什么是Django REST framework（DRF）？

Django REST framework is a powerful and flexible toolkit for building Web APIs.

上面是官网的介绍，我稍微修改一下可能更清楚：

Django REST framework is a powerful and flexible toolkit works with Django for building Restful Web APIs.

翻译过来：DRF是一个强大灵活的Django工具包，用于在Web后台构建Restful接口

在Django下构建Restful接口的工具不止一个（比如Tastypie），但是当下最出名的就是DRF，版本更新速度快、社区活跃度好，文档比较完善。

二、DRF有什么优势？

Some reasons you might want to use REST framework:

• The Web browsable API is a huge usability win for your developers.
• Authentication policies including optional packages for OAuth1a and OAuth2.
• Serialization that supports both ORM and non-ORM data sources.
• Customizable all the way down - just use regular function-based views if you don't need the more powerful features.
• Extensive documentation, and great community support.

上面同样是官网的介绍，我稍微翻译一下：

1. 提供了可视化的API调试界面，开发者可以在线测试接口
2. 提供了各种开箱即用的API认证授权工具，如OAuth2
3. 提供了orm数据序和非orm数据的序列化支持
4. 支持函数视图
5. 大量的文档和社区支持

上面的说法可能不够直观，我站在API提供者的角度来列举几个好处：

1. 安装到Django工程中，你就能在Django中提供Restful接口了
2. 你可以在一个Web页面上浏览自己提供了哪些API，并且可以通过这个页面测试这些API
3. 你不用自己写一套接口鉴权代码了
4. 你不用自己写大量的CRUD接口了，简单配置即可
5. 你不用自己写大量的条件查询接口了，简单配置即可
6. 你不用自己写后台分页逻辑了，简单配置即可
7. 你不用自己写接口限流逻辑了，简单配置即可
8. 你不用自己写各种简单的参数校验逻辑了，简单配置即可
9. 你不用自己注册各种路由了，简单配置即可
10. 你的权限控制逻辑不用写到业务逻辑中了
11. ...

可能还有更多优势，但是鉴于本人的使用程度有限，所以只能先列举这些，期待大家的补充~

三、你是否需要DRF？

记得第一次尝试DRF的时候，按照官方文档走完了Tutorial，并简单理解了DRF的一些重要元素，比如Serialzers、ViewSets等，但是最终用到项目中，还是感受不到它的优势，反而觉得：这东西，用起来的成本有点儿高，感觉又学了一个Django框架？相信很多人刚开始用都会有这样的困惑，所以我开始思考，什么情况下需要用DRF？

先从项目规模来看，如果是小项目（几个简单的接口和页面），用Django的FBV足矣，简单明了，学习成本低；中大型项目、多人参与的项目，建议使用DRF，虽然学习路线较长，但是长期来看，效率和规范性都更高。为什么这么说？我们可以看两张“糙图”（画的不是很精细）：

上面这张图是Django中开发业务逻辑涉及最多的内容，设计好db后，在urls中定义路由，在views中添加视图函数，并编写业务逻辑，十分简单。但是视图函数很自然会写成下面这个样子：

校验逻辑和业务功能很容易耦合到一起，视图函数也很容易被“搞大”，很容易出现重复代码多，函数过长，不好维护等问题。除此之外，接口地址的命名，接口返回格式等都需要额外规范来统一。

再来看这张图，借助DRF，我们可以将接口的开发过程规范化，形成一个统一的代码工作流：Serializers负责数据的序列化和反序列化，结合Validators可以低成本的实现参数校验、Permissions负责权限校验、Routers负责路由自动注册、通过重写框架定义的函数，还可以统一接口返回格式及异常处理等。简而言之，就是DRF为我们定义好了在什么位置写什么代码，开发都按照这个规范来写，接口才能正常工作。

通过Django+DRF，我们还可以很快速的配置出一套Django模型的CRUD接口，将一些开发工作变成配置工作，借助一些DRF周边工具，如django_filters，可以快速实现模型数据的过滤类接口，降低了开发成本，并保证接口规范统一。

其次，我们重用DRF的另一个原因是项目分工的精细化，通过引入前端团队，将原来的模板直出的方式优化为前后台分离，页面渲染的数据都通过Restful接口来提供，前端工程化，后端服务化，代码解耦，开发效率更高。

四、学习DRF的最佳方式是什么？

回忆起来，和学习Django的路线差不多，先把Tutorial 走一遍，然后将重要模块的文档单独拎出来看下，比如Serialzers、ViewSets和Routers；最后，找一个旧项目或者新项目实践下，实践过程中多看看文档和源码，多总结，慢慢就熟悉了。

概念性的东西和问题就总结到这里了，感兴趣的同学可以先把Tutorial 走一遍，熟悉下DRF的基本用法。接下来，我不打算直接介绍DRF的知识点，而是从“安装DRF”开始，在蓝鲸应用开发框架的基础上，一步一步地配置好“DRF脚手架”，并在脚手架的基础上，一点点地总结工作中使用DRF的技巧，希望能帮助到一些蓝鲸应用开发同学们~