API设计模式1
什么是好的API
- Operational
功能需求+非功能需求 都能满足 - Expressive
能够便捷准确表示和达成用户的诉求，同时支持的功能都要能够访问（隐藏功能） - Simple
简洁不代表数量少。
“让常见情况变得出色，让高级情况成为可能”。这意味着每当您添加可能会使API变得复杂以造福高级用户的功能时，最好将此复杂性对普通用户进行充分隐藏。这样，更频繁的情景变得简单和容易，同时仍然为那些高级功能提供支持。 - Predictable
相同API的入参命名应该相同，比如都传入string类型，都命名为"text"
命名
数据类型与默认值
2 + 4 = 6 还是等于 24 ？
省略 vs null
fruit1 = { name: "Apple", color: "red" };
fruit2 = { name: "Apple", color: "" };
fruit3 = { name: "Apple", color: null };
fruit4 = { name: "Apple" };资源
将我们的注意力从操作转向资源使我们能够通过利用简单的模式更轻松、更快速地熟悉API。但这也意味着要更加慎重的定义API资源
资源类型的关系
如message属于user，这种引用关系也可以成为外键，或者视为一对多关系
ChatRoom和User则属于多对多关系
自引用关系，同为user，但可能有employer
层级关系，如ChatRoom包含Message，删除ChatRoom对应的message也会删除
是否需要一个关系？
- 建立关系是有代价的，性能变差，维护复杂
- 关系也是有价值的，比如社交网络
- 新增关系一定与某个重要的业务需求挂钩
内联还是引用？
按照具体情况讨论，如果需要获得管理员的姓名，内联只需要调用一次api。但也可能会产生的大量的数据。
层级还是引用？
当我们删除一个聊天室时，我们几乎肯定也希望删除属于该聊天室的Message资源。此外，如果有人被授予访问ChatRoom资源的权限，如果他们没有权限查看与该聊天室相关联的Message资源，那么这似乎并不合理。这两个指标意味着我们几乎肯定要将这种关系建模为一个适当的层级结构
换句话说，如果您考虑的是一对多的关系，那么层级结构肯定不是一个好的选择。例如，Message资源应该始终属于一个单一的聊天室。如果我们想将单个Message资源与许多ChatRoom资源相关联，那么层级结构可能不是正确的模型。
不好的模式设计
万物皆资源
很多人有时会忍不住给最微小的概念创建资源。通常，这种做法的出现是因为人们认为任何数据类型都必须对应一个适当的资源。例如，想象我们有一个API，可以在图像上存储注释。对于每个注释，我们可能希望存储注释区域（可能以某种边界框住特定面积）以及构成实际注释内容的注释条目列表。
在这一点上，我们有四个独立的概念要考虑：图像、注释、边界框和条目。问题是，其中哪些应该是资源，哪些应该仅仅作为数据类型？
更改后，将不相关的资源改成数据类型
