【API】一次编写api引发的总结

写在前面的话

今年公司的工作重心放在了APP的开发上,后端的职责就是负责为APP提供正确且精练的数据,这样APP才能活起来。最近张总要我实现几个简单的API接口,在此过程中躺了一些坑,这里总结出来希望对大家有一点帮助。

数据库的设计

1.思维导图上画出表与表之间的关系

当接到任务时,先正确理解业务需求。之后建立数据库业务表,再创建关键字段,一些额外字段或者以后提出新的需求需要增加字段时以后再考虑,这些需求在设计前期可能没考虑到,先保证目前的业务逻辑关系是正确的,能跑通。想的太长远有时候也是一种思想负担,我一般会考虑这个地方在未来两周内会不会有什么变化。这也体现简单的敏捷开发的思维,快速迭代。

2.良好的逻辑设计和物理设计是高性能的基石

3.数据库类型的选择

选择适合该字段的最小存储类型

占用操作系统的资源少(内存,磁盘,CPIU告诉缓存)。原因:Mysql是通过文件形式持久化在系统中,当我们查询时数据要先通过页的方式加载进内存(避免内存撑爆,通过页加载只是加载磁盘上一部分数据),页的大小是固定的,如果每一行的数据占用的空间小的话,能加载进内存中的记录就更多。这样数据命中率也就高了。比如手机号码不会超过11位,在LARAVEL中数据库迁移文件中string如果不指定长度默认的数据库类型是varcha人(191)。对于varchar数据类型来说,硬盘上的存储空间虽然都是根据实际长度来分配存储空间的,但是对于对于内存来说并不是,其使用固定固定大小的内存块来保存值。

将字段设置成非负

比如数据库冗余的count_follws不可能存在为负数的情况

关联字段,数据类型保持一致,否则会导致索引失效

4.索引的建立

区分度不高的列不需要建立索引

Mysql查询优化器会评估索引的效率,如果使用的是区分度不高的列更具评估结果它会觉得全文搜索和索引搜索效率差不多而使用全文搜索。但是创建了索引,就会在系统中维护索引树,占用系统资源。

表之间的关联字段要建立索引

经常查询的列也需要建立索引

当多个字段经常在一起同时使用时,可以考虑建成聚合索引。

5.给字段取个好名字,字段注释   相当于注释,方便日后开发的团队工作效率

还有很多数据库设计技巧,这里就一一列举了,欢迎私底下交流。

为什么要设计优雅的API

1.易于使用,移动应用的 API,服务器端和客户端分别由不同开发人员负责。Api的目的是让更多的用户更简单的使用,设计的好坏就很重要了。

2.易于更改,由于人们对需求的理解在变化,我们为APP提供的服务可能发生变化,从而不得不改变API。但是又要保证更改 API 时尽量不影响正在使用APP的用户。做到这一点自然水到渠成。

3.健壮性,比如服务器处理逻辑出现错误,我们不能直接抛出500 页面。一定要转换成普通用户能看的懂的提示。还有网络安全问题开发初期系统没有集成,该阶段注重开发功能。

如何写出优雅的API

1.永远不要相信用户的输入:1.数据输入的校验前端可能会做,但是一些敏感的数据还是要在后端校验一次。

2.友好的错误异常处理,错误LOG能还原错误或异常的车祸现场,APP调用者能获得友好提示

3.API规范化,API到时候会很多,我采用了张总的方式:将不同类型的API放在不同的文件中分类管理。API的路径采用Restful风格,一个结构清晰,易于理解的API可以省去没有意义的沟通。建立API说明文档方便APP调用者整合接口。减少沟通时间。

4.多测试,错误往往藏在你的自以为是上.

5.代码思路清晰,代码注释,需求经常改变,通过注释减少重复思考时间。API尽量用简单的方式实现,代码结构思路要清晰(有时候代码写得好注释都可以不要)。

结束

1.多沟通,API就是纯的业务,体现的技术很少。当业务理解到点,基本上就没什么问题。

2.修改代码一定要测试,就算修改一个小地方。你可能会觉得改了某个地方一定不会有问题,但是有时候偏偏就是你的惯性思维误导了你,所以说个人经验是双刃剑,看你怎么用了。

3.站在使用者的角度上思考问题,好的API设计应该是符合直觉,能望文生义的,让使用者能用尽量简洁的代码完成调用。

4.对自己写的代码有不同角度的审视:1.在实现层次:对象是代码和数据 2.规约层次:对象是一组可以被其他对象或自己调用的方法 3.概念层次,对象是一组责任即这个对象要负责干什么事。


目前只想到这么多,欢迎大家补充。

日记本

如果觉得我的文章对您有用,请随意赞赏。您的支持将鼓励我继续创作!

赞赏支持
被以下专题收入,发现更多相似内容