Bezos比軟體工程師更理解API

The Bezos API Mandate: Amazon's Manifesto For Externalization | Nordic APIs |

關於Bezos的「API命令」，這可說是科技史中堪稱是教科書等級的一個大事件。雖然這當然不是新聞，會看科技媒體的應該都有瀏覽過，但我想以自己的角度也深入去思考一輪，輸出跟大家分享。

這是在2002年的事，當時還是Amazon的CEO的Bezos，為了徹底強化在AWS的骨幹系統，不論是在效能上還是在思維上，他下達了這個重要的命令。遵循著Amazon一貫的簡潔明瞭的文件作風，內文很簡單就7點而已：

1. All teams will henceforth expose their data and functionality through service interfaces.
2. Teams must communicate with each other through these interfaces.
3. There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.
4. It doesn’t matter what technology they use. HTTP, Corba, Pubsub, custom protocols — doesn’t matter.
5. All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.
6. Anyone who doesn’t do this will be fired.
7. Thank you; have a nice day!

這7點的翻譯本身不是重點，真正的重點是Bezos想"改造"Amazon體質的那些思維。

去除「窗口」，打破孤島，強迫協作

API是一種具「疊加性」的溝通方式，和我們認為方便的「一站式」服務有很大的不同。我們要取得其他單位的服務，若只是找到窗口，簡單說一聲要什麼資料或服務，剩下的"運算"就都得由這個窗口執行。

但API通常都只是提供一些基礎的功能而已，用戶想要什麼資料，想要什麼服務，就得靠這些基礎的「零件」自己打造。雖然對不習慣，沒經驗的用戶，會需要一段時間學習及開發，但一回生二回熟，其實學習曲線也不算高，很快就能串起自己要的"功能"。

由於不能再透過其他的方式交換資料及服務，所有單位就必須提供出足夠的API介面。不管是工程單位，財會單位還是業務單位，沒有一個單位可以置身事外，可以要求別人follow他們的規矩。因為規矩只有一條 - 你得把你的介面貼出來。這不但打破了孤島效應，也間接的強迫協作，沒有什麼東西可以被「人」藏起來。

文中提到說，有人質疑這樣的作法不合理。讓窗口為需要服務的單位，提供"最佳化"的服務不是應該比較好嗎？但我們大家的實務經驗都知道，只有我們自己才知道，怎麼樣的服務是對自己最好的。此外，也因為透過這種自助式的資料及服務存取，反而造就了更多不同的服務，將同樣的資料及服務，弄得像24小時均可販售的自動販賣機一樣，也收獲了更多的價值。

溝通的「效率」來自於介面的一致性

由於API天生的特性，就是將實作細節給封裝起來，這無疑就打破了低效溝通的最大元兇 - 介面的不一致性。

當你向業務部門要資料，它只能給你Word檔；向財會部門要資料，它給你的是Excel；你問了下後台的數據如何，它用SQL查給你；要查一下產品的規格的話，可能是一個網頁或是PDF等等。這是不同的資料介面，拿到資料後你得自己整理成需要的樣子。

同樣的，要求不同的部門服務時，有的人處理完是回電給你，有的人是用LINE通知，有的人會走過來直接跟你說一聲等等。這是不同的功能介面，你得瞭解每個人或每個部門的「眉角」，排出一個合理的工作流，才能比較順暢的把事情處理好。

這一些若是有了新的部門，新的資料，新的執行窗口，就會讓執行的效率再有新的變數。

一但所有的協作都"只"用API進行，不管API後面是哪種資料庫或函式庫處理的，用戶只在乎API是否有在預期的時間，得到他想要的回答。這全程沒有「人」的問題，就沒有所謂的「眉角」。就像《The Falcon and the Winter Soldier》中說過的：

The weakest point in any system isn’t the software, the hardware, it’s the meatware. The human element.

任何系統都有缺點，不是軟體，也不是硬體，而是人類。

協作的過程，只要有「人」進來成為存取資料及服務的節點，那通常就是效率最差的弱點。

另一個API帶來的優勢是「相容性」。資訊技術日新月異，永遠都會有更好的新工具，新軟體，新服務，新技術等等。而許多需求可能根本就和實作技術無關，若取得資料及服務的介面，是完全依賴在特定的工具或服務上(就像之前提到的Word/Excel/DB/PDF...)的，這就意味著有朝一日必然會遭遇"改版"的需求。

相反的，若一開始就訂好了API這種存取資料或服務的方式，那這API的底下是怎麼運作的，就是一個可以與時俱進的實作。反正用戶也不在乎你是怎麼提供服務或資料的，他只在乎有沒有辦法拿到資料。

從骨子裡就開始面對客戶，在血液中就流著用戶思維

Bezos要求所有的API，都要設計成可以直接提供外部用戶使用，而且沒有例外。以工程師的角度來說，這意謂著他們不能隨便亂加一些無謂的全域變數，無用的類別，也不能為了趕時間貪方便，就以破框的方式來開發系統；即便是非工程單位，他們的API除了要想怎麼跟內部團隊協作，也要去思考「真正的用戶」會需要什麼介面。沒經過大腦思考就亂訂一通，開出來的API，就像沒睡飽亂講話一樣。

API代表的，就是最終的商業邏輯，不論它是不是真的純商業行為。「只能用API交換資料，存取服務」，「API都必須能直接提供外部用戶使用」，「API才能保持其一致性」這些讓人很頭皮發麻，很"麻煩"的事情，才真的能促使整個團隊在面對自己的產品，都是從骨子裡就開始面對客戶，在血液中隨時流著的都是用戶思維。

沒照做的就請離開

不管Bezos的這個指令有多傳奇，多有真知灼見，但最重要的可能是第6點：Anyone who doesn’t do this will be fired。可想而知對非軟體工程團隊的人來說，這是一個多"不合理"，多勞師動眾的一個要求。但若不是Bezos的這道指令，若不是這麼強悍的執行力，Amazon就不是今天這個樣子了。