DAY07 - API架构分享

其实大家可能都有自己的API架构方式，不过我这边就是分享我目前在Web端撰写API时，在架构上和开发时会注意的事情，跟大家分享，也欢迎各位大大互相交流～～～

API需要什麽架构？不是用到的时候打API就好了吗？其实程序要怎麽写都可以，但就差在写法後续带给你的会是痛苦加班还是快乐下班ＸＤ 这边就来分享一下可以离快乐下班进一点的撰写原则~

ps. 後续范例皆以vue.js搭配axios的程序为例

原则1 把所有API用统一一只档案控管，要使用的时候在各自引用

在制作前端画面的时候，每个不同页面，都会有很多需要串接API取得资料的地方。若每个页面都分开打API取得资料，到时候要做管理的时候，就会变得很麻烦。
Ex.取得书本列表API，我在A、B、C页面各呼叫一次，如果之後取得书本列表的API URL或参数有修改，那我就需要在各个页面调整。

统一一个页面做API控管，有API相关的新增修改，就统一找这个档案，会让後续的新删修都一目了然也更好管理。

• 特别独立一个api.ts的档案，统一管理API
  

• 在需要的各页面中(ex.页面A/页面C)，引用同一来源的API function
  

原则2 共用的东西统一管理

其实是写程序的时候应该都要有的概念，当东西开始要重覆写好几次的时候，就应该要把它整合成统一的变数，让之後修改只要统一改这个变数就好了

2-1 基础设定、路径统一管理

API的基础设定、还有各个类别的路径可以统一管理，之後若要调整修改就可以很快地找到修改

2-1 错误处理统一管理

错误处理也可以用统一的function，让所有API呼叫有错误时，都呼叫此API错误处理的function。
提到错误处理，也厘清一下後端的错误处理回传方式，当API有错时，错误代码有两种给法:

WAY1 - 回传 http status code (参考连结)

当各个API有错误时，API传回给前端的错误代码是以http status code为标准。
例如：apiBookList有权限的错误，後端会直接用http status code - 403没有权限的错误代码回传给前端。 若apiBookList中，前端的参数传递的错误就给400(Bad Request)的错误代码。

WAY2 - 自定义不重覆的error code

後端提供一个error code的代码，并把所有不同错误的编号，回传给前端自定义的错误代码。

其实两种方式都可以，只要和後端讨论好即可。但我自己可能比较喜欢用第二种方式。原因是：如果使用http status code，若有两只API有同样的http status code但要做不同的错误处理，那就需要再额外判断是哪一只API。
ex.apiBookList 和 apiAddBook 都会有 错误的 http status code 400，但apiBookList的400可能表示的是排列的方式没有定义；apiBookAdd的400可能表示有必填的栏位没传给API。这就是同一种status code但不同API代表不同的意义。因此需要知道是哪一只API才能判断显示的错误讯息或接下来该显示的UI画面或流程。

• 回传 http status code，相同status code要不同处理时需多判断API是哪只
  

• 将所有不同的错误，定义成新的错误代码，只判断错误代码，即决定错误处理行为
  

原则3 区分环境

在开发时，基本上都会有正式环境、测试环境、开发环境。不同的环境，可能会有不同的API Path或是不同的API Base setting。这也是在api统一管理时，可以一起加入撰写的。

以上就是我的API几个小小的管理原则跟注意的方向的心得，可能也不是真的很完善，也欢迎大家一起分我分享怎麽管里可以更优化～
一起朝着未来修改程序可以快乐下班的路上迈进，我也还在努力RRR~~~