使用Rails构建一个TO-DO应用的JSON API (Part III)

第三部分,我们要做三件事情 1.版本管理 2. 序列化 3. 分页,以上都学会以后,可以开发完整的服务端了,全栈工程师~😯

额……在开始之前,我们先设置seed,假的数据,方便后面的测试

检查Gemfile

编辑db/seeds.rb

然后,本地开发环境重置数据库

如果代码已经提交到heroku,那么,heroku 重置数据库

好的,准备工作完成,开始进入正题

版本管理

最常见的场景,客户端1.0用到了一个API,但是下个版本1.1中,需要服务端改变同个API中的返回字段,但是用户群在客户端发布1.1以后不选择升级,那么服务端就需要适配两个版本的接口,需要引入版本管理。在Rails中,如果你需要做这件事情,你只需要做两件事:1. 添加路由约束,这会依据每个request的header选择不同的接口版本。2. 给控制器命名空间,controller中不同的namespace处理不同的版本 。

编辑

依据标准写法,检查这个外链,很明显header里面有对应版本号的字段。从request对象,进入Accept的headers,然后检查版本信息,找到对应的接口,这个过程叫做content negotiation,外链,简单讲就是同样的URI对应不同的版本,服务端驱动的版本管理。依据Media Type Specification,你可以通过vendor tree自己定义media types,比如application/vnd.example.resource+json

好的,现在我们已经有了约束的类,接下去需要改变路由。由于我们不会改变URI来做版本管理(顺便说一句这是错误的做法,是反设计的,但很多公司仍然在使用😄),所以我们会使用module scope和namespace。

编辑config/routes

version constraint是全局有效的,v1是默认版本,也就是说没指定版本就是v1。如果我们指定新的版本,Rails会从高到低去匹配版本号,使用那个matches方法。然后我们看到controller,建立文件夹

把相关文件移动到这个文件夹下面

还没完,记得加module的版本号,看到app/controllers/v1/todos_controller.rb

同样的,app/controllers/v1/items_controller.rb

接下去是v2的版本

编辑config/routes.rb

注意顺序,不是默认的版本要在默认的版本上方

编辑app/controllers/v2/todos_controller.rb

因为只是测试用,所以就给条消息吧

用v1登陆,拿到token用给v2的todos发get请求,是有效的也是正确的

序列化

这是个很重要的特性,经常有这么个段子,客户端问服务端,我要新加个字段,你要多久。服务端说,是已经有的字段吧,几分钟的事情。嗯?这么快,为什么?那是因为序列化😄

这里举个例子,我需要一个todo的内容,还有他对应的所有items数组,总不至于请求两次API吧。使用Active model serializers ,检查Gemfile

bundle install 以后

会有一个新的目录app/serializers,以及一个新的文件todo_serializer.rb,编辑

item的哪些属性需要序列化,以及item和todo的关系。用httpie再测试下吧

看到我请求了todo,返回了todo的属性,还有这个todo下的所有items

分页

已经接近完成了,由于在真实环境中,数据可能非常多,我们不可能一次返回所有数据,所以我们需要一个功能叫做分页,让数据批量次序返回,对应于前端的上拉加载更多功能

检查Gemfile:

bundle install

编辑app/controllers/v1/todos_controller.rb

可见,每次返回20条数据,用httpie试一下是不是20条数据,这里就不贴图了

注意如果page==0,那么返回所有数据

使用Rails 5写RESTful API,真的很高效,赶快实践下吧,小伙伴们😄

这是我部署在heroku上的应用:

https://desolate-sea-54055.herokuapp.com/

完整的git项目地址:

https://github.com/HongliYu/todos_api



发表评论

电子邮件地址不会被公开。 必填项已用*标注