无论在文档还是代码中，对API的分类，差不多都是从插件层次进行的，比如说Database Api、Reputation Api、Follow Api等等，这样做的好处是一个插件对应一组API，但是缺点是不同功能混杂到一起。
(图源 ：pixabay)
那么如果要实现一个给用户使用的库，是否可以考虑从功能角度来给HIVE的API分类呢，我想了想，这样应该是可行的。我简单归纳总结一下，大致可以按如下模式划分。
基础类别
基础类别应该包括最基本信息获取，比如获取当前区块链信息、读取区块、获取config信息等等。
除此之外，还应该包括Transaction的创建、序列化、签名、广播等等。
基础类别是所有类别的基石，我们既可以直接通过基础类别来完成任意操作，也可以在其上来实现/封装各种类别，便于用户使用。
封装类别
把基础类别之外的，所有基于基础类别封装而实现的类别统一称作封装类别（当然了，其实叫啥不重要）。
大致可以分为以下一些功能模块：
- 社交类(social)：包括发帖(post)、回帖(reply)、点赞(upvote)、追随(follow)等等
- 见证人(witness)：包括witness投票、喂价、更新信息、上线/下线等等
- 交易类(market)： 包括买卖、查看行情、订单管理(查询、取消等)
- 资产类(asset)：包括转账(transfer)、Power Up/Down、存取款、转换等
- 账户类(account)：查询账户、修改密码/KEY、修改账户恢复人、授权/取消授权、更新资料等等
- 中介交易(escrow)： 和中介交易(escrow)相关的功能
- 提案相关(proposal)：和提案系统(proposal system)有关的内容
当然了，这个概况可能并不全，比如说社区的管理等等，或者其它可能我没提及到或没了解到的内容。
补充说明
感觉这样分类一下，相关逻辑会变得更清晰一些，并且代码应该也更利于维护，毕竟把很多代码放到一个文件中，操作起来会有些晕呢。
当然了，这很大可能是因为的水平太低，对Python之类的语言用的还不是得心应手的缘故。
(图源 ：pixabay)
不过这都没关系，我相信只要每天能进步一点点，日积月累总会有所收获，毕竟我要超越的不是别人，而是我自己呀。
This page is synchronized from the post: ‘每天进步一点点：从功能角度分类 API’