面食窗口的API设计之道

用户1842383338554
133 阅读4分钟

前言

相信每个开发者对于API都不会陌生，最近几十年，随着软件工程行业的发展，自造轮子的情况已经少之又少，每天的工作都不可避免的要用到其他模块或提供提供的API，也有不少人要开发API给其他人用。这篇文章呢就是以面食窗口为案例来介绍API设计的一些原则和思路，希望能帮到大家。
故事就从下面这碗香辣牛肉面开始。\


这里写图片描述\

API的意义

  • API设计非常普遍
  • API设计影响范围广泛
  • API设计影响持续时间长
  • API设计技巧抽象难以理解

面食窗口的 API演进

假设管理食堂的面食窗口，
为大家提供面食服务就相当于为大家提供API服务，其他人扮演着客户端的角色，通过API向你获取面
请的是祖传刀削面和汤底的师傅，这个是你独特的竞争优势
你只提供香辣牛肉刀削面作为故事的开始。\


这里写图片描述\

第一天，生意开始

策略：
统一销售牛肉刀削面
API:
http://localhost/api/v1/noodles

客户端：来一碗刀削面
客户端：来一碗刀削面
客户端：来一碗刀削面，不要香菜
服务端：500，我们这都有香菜，不能不加

新的业务需求引发了接口变更的需求
接口发生变更时尽量向后兼容，新增而不是修改接口

第二天，生意更好了

策略：
销售牛肉刀削面,单独不要香菜的接口
API:
http://localhost/api/v1/noodlesWithoutXiangcai
http://localhost/api/v1/noodles

客户端：来一碗刀削面，要香菜
客户端：来一碗刀削面，不要香菜
客户端：来一碗刀削面，不要香菜
客户端：来一碗刀削面，不要辣椒
服务端：500，我们这都有辣椒，不能不加
客户端：来一碗刀削面，要宽的
服务端：500，我们这都是细的，

当不得不调整参数时应建立新的接口

第五天，一切都看起来不错

策略：
销售牛肉刀削面,可以配置是否要香菜，是否辣，是否是宽的
API:
@Warning
http://localhost/api/v1/noodlesWithoutXiangcai
@Warning
http://localhost/api/v1/noodles

http://localhost/api/v1/noodles?xiangcai=1&hot=1&suancai=0&huasheng=1&......

业务场景
客户端：来一碗刀削面，要香菜要辣不要酸菜不要花生
客户端：来一碗刀削面，不要香菜要辣不要酸菜不要花生，
客户端：来一碗刀削面，不要香菜要辣要花生不要酸菜
客户端：来一碗刀削面
服务端：500，条件不足

客户端需要了解不必要的业务细节
改进：封装己方核心业务逻辑，提供工具和可组合使用的接口，将业务灵活性交给客户端

第十五天，生活真美好

策略：
3步法定制：
1.获取默认调料
2.定制口味
3.根据口味获取面食
API:
@Warning
http://localhost/api/v1/noodlesWithoutXiangcai
@Warning
http://localhost/api/v1/noodles
@Warning
http://localhost/api/v1/noodles?xiangcai=1&hot=1&suancai=0&huasheng=1&......
http://localhost/api/v1/flavoringTemplate
http://localhost/api/v1/noodles?mode=宽&flavoring=gg

客户端：来一碗默认的刀削面
服务端：好的

客户端：都有哪些调料
服务端：这个就是调料包
客户端：这个是我要的面的口味（组合调料包），给我我要的面，宽的
服务端：ok，稍等

最终状态

面食窗口不但提供刀削面还提供粉等类似的食物。
业务流程：
1.用户向框口提交基本要求，什么面，大小碗
2.窗口将面交给用户，同时提供给用户一个自助区域
3.用户到自助区域内添加自己喜欢的调料
4.口味调整好后，可根据需要再把面交给窗口添加独家汤底

至于API情况大家可以自己想想该怎么实现。

总结

在这篇文章中，我们通过面食窗口的服务模式的变更说明了API设计的注意事项和主要原则
下面简单列一下API设计和开发基本原则：

  1. 新增而不修改
  2. 封装核心业务逻辑
  3. API名副其实
  4. 每个API只做自己应该做的事
  5. 服务端尽量不存储状态
  6. 接口尽量少
  7. 支持组合使用

此外还有就是API的版本管理要注意，不是说废弃就能废弃的。

avatar
文章
阅读
粉丝