前言

昨天我们实现了用户相关的接口，今天我们来实现文章相关的接口

项目地址：

由于我是先实现完再写的这篇文章，如果有些地方无法运行，可以看下我项目里的代码。

目前我还在往全栈的方向学习，所以如果看的不顺眼，请多多包涵。如果觉得那里可以改进，麻烦评论区说下，谢谢~

增/改

增和改的逻辑基本上都是一样的，所以复用同一个接口即可。

实现

我们现在src文件夹下创建article文件夹，然后在里面分别创建四个文件

注意这里的db_service以及route和auth里的名字是一样的，但是并不会有冲突，因为它们都只会用在文件夹里面。

然后我们在mod.rs中引入它们

接着我们先去到type/mod.rs中新增一个类型，这个类型用于存储token里用户的id，这么做是为了校验是否是作者本人。如果不是，直接扔给400。

然后我们为增/改新增一个类型

• SetArticleData：这个用来和post传输过来的form对应。
• SetArticleDataState：这个作为Response时和RtData组装的类型。这里我只返回修改的时间。

然后回到route.rs中直接上代码

代码稍微有些长，但是非常好理解。

就是拿到数据后组装md文件的存储路径，将它存储在src同级的md文件夹里，以md/${author_id}/${article_id}作为路径。

如果id不为空，那么就是set，否则为add。add的场景会创建新的.md文件。

我们来实现这里的save_article,回到article/db_service里面

在这一步创建时间戳，表示最后的修改时间，插入/修改成功之后返回modify_time。

然后我们去到file_operate文件中

方法很简单，就是对文件的读和写，如果中间过程出错直接return Err(500)。

然后我们去到main.rs中注册

测试

第一步我们需要登录，拿到_token再进行下一步新增文章

拿到token之后放到Header的_token字段中。

然后我们再调用/user/set_article

然后回过头来看文件夹中多了一个.md文件

那么插入就成功了，如果不放心，可以去数据库里看下

然后我们再来测试下修改

把id也带上

测试正常

删

实现

删除的就比较简单了

我这里只是删除该id在数据里的索引，文章内容还是保留着。

当然，还是得判断是否是同一个用户。

去到article/db_service中

先查询下对应的文章是否是改用户写的，然后再删除这一列。

别忘了去注册路由，我这里就不贴代码了。

测试

记得先拿到_token

我们看下数据库里是否还存在该条信息

可以看到没了

获取文章详情

实现

老样子，这个也是需要获得用户的id用于匹配是否是作者本人，这样我们可以判断该用户是否可以对文章进行编辑

我们先实现文章细节的类型，去到article/mod.rs中

这一套轻车熟路，就不用我都说了。

然后我们回到article/route中实现路由

然后去到article/db_service中

另外db/mod.rs中补充下一些内容

对于一些常用类型的封装

别忘了去注册路由~

测试

。。。刚刚就不应该先测试删除的。。。

这样就只能重复 登录 -> 新增 的操作了。

获取成功

分页查询

实现

这个接口我们可以和/根路径接口重合,根路径重定向去到我们的分页查询路由

老样子，我们先补充下类型，去到type/mod.rs

然后回到我们的路由文件

对于/路径，直接Redirect[1]到get_article路径

然后去到db_service中

如果all为true，则分页查询，如果all为false，id不为空，则查询单个。

呃。。。这个函数有些问题。。。对于查询单个的场景没有做limit移除处理。。。只能由前端自行调整了。

另外有个点需要注意，那就是只有is_publish为true的文章才能被这个接口查询到。

而is_publish为false则表示是草稿状态。

注册完之后我们来测试下

测试

获取单个

获取多个

正常。

模糊查询

实现

这个主要是用在搜索栏里的，这个东西要搞可以搞到非常非常复杂，比如深度神经学习、大数据什么的。。

而我这里只是个demo，简单的通过字符串匹配

老规矩先上类型，article/mod.rs中

然后回到route.rs中

然后db_service

这里根据的是pgsql提供的%[key]%来模糊查询

测试

正常

总结

那么到这里就差不多了，这一个demo主要是带大家（包括我自己）入门以及熟悉下rust代码的编写

实际上很多东西我都没有去实现，比如：

1. 接入log日志
2. 类型整理，RtData的类型太多了，导致重复的实现太多了，实际上可以整合成一个枚举类型
3. 缓存，redis
4. 优化io操作，每次set/add都是io操作，这样会有很大的性能问题
5. sql语句优化
6. 其余接口实现，比如获取用户自己的草稿列表等。

最后如果你觉得这些文章对你有帮助，请务必点个赞~

吐槽：卧槽了，公司项目的重构是真的恶心，本来还以为能划水，现在搞得还不如做需求呢。。。

参考

1. ^Redirect https://api.rocket.rs/v0.5-rc/rocket/response/struct.Redirect.html

发布于 2023-06-07 18:01・IP 属地广东