各家API的比較

目標們:
* 91APP
* cyberbiz
* EasyStore
* friday
* iopenmall
* MOMO
* MO+
* PChome
* shopify
* Shopline
* Yahoo購物中心
* 樂天
* 東森
* 博客來
* 蝦皮
* Coupang
* 露天

API評斷

完整<<API的功能
完備<<API功能之間的互補性

完備的API就是打一次API資料裡面幾乎相關的都有不需要打第二次或是其他的
完整的API就是功能的廣度，UI上的操作幾乎都可以用API完成

API完整性(API支援度)

1. 蝦皮
2. shopline
3. shopify
4. 91app
5. momo

極度不完整
博克來

API完備性(API設計的完整度)

1. shopify
2. shopline
3. 蝦皮 (它的好處是綁IP但不限速)
4. cyberbiz
5. easystore

極度不完備
東森

API限速的規則

1. 漏桶演算法(shopify)
2. 綁IP
3. 限制速度(By 帳號 or IP) 都有

漏桶演算法

漏桶演算法可以符合大家不會隨時爆量，用綁IP或限速的方式來達成客戶的需求，以API的使用上來說算是比較好的方法

eq:水桶大小40 每秒流量 2，每秒請求兩次沒問題，就算短時間大量請求，湊滿四十次，只要後續有休息20秒就可以持續請求

大小跟流量可以特殊設定($$)

Rproxy（Reverse proxy） 與 proxy的比較

rproxy 指定server當DNS代理後轉拋
proxy 打http時帶proxy轉拋

以電商的多廠商情境，比較簡單的做法是rpoxy但是比較正確的做法是header的rproxy or proxy

Header rproxy

API 取資料換頁的取法

1. 資料本身不分頁 直接吐回(太多ERROR請更換條件)
2. 資料分頁 “即時”按照條件吐回
3. 資料分頁給上下頁的token (用token其他條件跟第一頁相同)

API根據第一頁條件用linkedlist-id鎖住給token，是目前看來最好的做法

安全機制

1. 真第三方 (真的有第三方授權機制 並且移除原本帳密機制 且有定期刷掉)
2. 假第三方 (有第三方 也有原本帳密機制 時間設定超久或是不限)
3. 無第三方有換密碼時間 (momo)
4. 無第三方也無換密碼時間(東森)

Webhook機制

1. 透過API設定整個平台性的(根據TOPIC回傳 eq:蝦皮 ,舊版shopline ,easystore)
2. 透過第三方平台設定的webhook(shopline為代表)
3. 部分需求透過webhook打回，避免API請求的時候過長(yahoo的商品)

根據情境，一些要跟客戶溝通的東西，與其他們來問我，不如我們通知他，因此這三個場景都算減輕壓力的方法

API設計面向

1. 有照restful
2. 有ddd方向
3. 有完全客製化(API path想怎樣就怎樣)
4. 有完全不遵守http method的(get帶加密的body)
5. 有把header資訊回傳當重要資訊的
6. 有因為透過AWS等轉拋，所以要考量AWS的傳輸限制的
7. 有各種content-type、然後不照這個type做事的

打API出去的底層工具限制的越少越好，要把所有的權限給使用工具的場景

結論

這是一個軟硬結合很吃重的題目、軟的過多查問題困難、硬的過多彈性出不來、design pattern中的工廠能解部分、但是再下去code還是要寫得越簡單越好