Bezos比軟體工程師更理解API
閱讀時間約 7 分鐘
關於Bezos的「API命令」，這可說是科技史中堪稱是教科書等級的一個大事件。雖然這當然不是新聞，會看科技媒體的應該都有瀏覽過，但我想以自己的角度也深入去思考一輪，輸出跟大家分享。
這是在2002年的事，當時還是Amazon的CEO的Bezos，為了徹底強化在AWS的骨幹系統，不論是在效能上還是在思維上，他下達了這個重要的命令。遵循著Amazon一貫的簡潔明瞭的文件作風，內文很簡單就7點而已：
- All teams will henceforth expose their data and functionality through service interfaces.
- Teams must communicate with each other through these interfaces.
- 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.
- It doesn’t matter what technology they use. HTTP, Corba, Pubsub, custom protocols — doesn’t matter.
- 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.
- Anyone who doesn’t do this will be fired.
- 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就不是今天這個樣子了。
為什麼會看到廣告
34會員
69內容數
Google實驗室Area120釋出了一個「製作遊戲」的遊戲叫「Game Builder」。
主要的用戶是遊戲編導，方便他們以拖拉卡片的型式來驗證遊戲性好不好。
因此這個專題就是「Game Builder」的"真心話(好用難用都會說)"和"大冒險(真的來挑戰看看能做什麼遊戲)"囉！
留言0
查看全部
你可能也想看
Google News 追蹤
徵的就是你 🫵 超ㄅㄧㄤˋ 獎品搭配超瞎趴的四大主題，等你踹共啦！還有機會獲得經典的「偉士牌樂高」喔！馬上來參加本次的活動吧！
隨著理財資訊的普及，越來越多台灣人不再將資產侷限於台股，而是將視野拓展到國際市場。特別是美國市場，其豐富的理財選擇，讓不少人開始思考將資金配置於海外市場的可能性。
然而，要參與美國市場並不只是盲目跟隨標的這麼簡單，而是需要策略和方式，尤其對新手而言，除了選股以外還會遇到語言、開戶流程、Ap
API（Application Programming Interface，應用程式介面）可以視為不同軟體系統之間的溝通橋梁，讓雙邊可以交換數據並執行各種功能。這篇會記錄產品經理一定要知道的幾個 API 概念，像是常見的錯誤代碼以及不同的 HTTP 方法（如 PUT、GET、POST）和實際案例說明
雲端已經成為App開發的核心，而Amazon的AWS（Amazon Web Services是開發者常用的平台，可以幫助開發者建立、整合和擴展App。
為何很多公司很怕Amazon？
亞馬遜有大筆資金可以侵入其它公司的專業領域
擁有電商平台、Alexa助理，進而可以搶走Google search或其他網站上搜索流量然後掌握顧客數據
亞馬遜本質上不是一家電商或科技公司，他是一家基礎設施（雲端計算、物流）公司所以具有強大的核心競爭力
Amazo
當我們在開發一個AI應用服務時， 常常會需要載入大模型， But… 我們總不可能每一次的請求就載入一次模型吧！ 這樣太沒有效率了， 也非常的浪費資源， 因此我們通常會希望應用程式啟動時就能夠載入模型， 之後每一次的請求只要讓模型進行運算即可， 那麼在FastAPI的框架中究竟要如何使用呢？
首
※ 什麼是 RESTful API？
這種運用 HTTP 來表達語義的路由設計風格稱為 RESTful API，它描述了如何實現 Web API 的架構。所謂的 API 是應用程式介面 (application programming interface)，網址也是一種應用程式的「介面」，故稱為
當我們在撰寫一套系統的時候， 總是會提供一個介面讓使用者來觸發功能模組並回傳使用者所需的請求， 而傳統的安裝包模式總是太侷限， 需要個別主機獨立安裝， 相當繁瑣， 但隨著時代的演進與互聯網的崛起， 大部分的工作都可以藉由網頁端、裝置端來觸發， 而伺服端則是負責接收指令、運算與回傳結果， 雲端
這篇內容精華重點：一個是 Open AI 執行長分享了一篇「希望有人早點告訴他的幾件事」，從過來人的角度分享他年輕時會希望有人告訴他的事情，很有啟發，還有一部影片是我認為人生必看 TED 的演講，叫脆弱的力量，告訴我們與脆弱相處的方法跟重要性。
Webhook 提供一個「即時觸發」的資料傳送方式。Webhook 與 API 的差異及在自動化流程中的作用是什麼？它讓你在事件發生時獲得通知。透過生活化的情境舉例，理解 Webhook 的運作原理，並了解如何透過 No Code 自動化工具設定 Webhook，實現自動化整合，提升工作效率！
先前幾篇筆記介紹了網路請求，瀏覽器儲存資料的方式，那麼實務上，前端最常需要發送網路請求的時候，就是透過呼叫 API，去向後端工程師發送/請求資料，所以今天來記錄什麼是 API吧！
在沒有分環境之前，每一隻lambda只有一個code console給所有人一起編輯，開發好了就deploy，根據設定的trigger觸發執行。
現在我們希望能夠在code console開發，然後deploy到不同的stage，目標是不同stage的api gateway能夠調用該lambda的
徵的就是你 🫵 超ㄅㄧㄤˋ 獎品搭配超瞎趴的四大主題，等你踹共啦！還有機會獲得經典的「偉士牌樂高」喔！馬上來參加本次的活動吧！
隨著理財資訊的普及，越來越多台灣人不再將資產侷限於台股，而是將視野拓展到國際市場。特別是美國市場，其豐富的理財選擇，讓不少人開始思考將資金配置於海外市場的可能性。
然而，要參與美國市場並不只是盲目跟隨標的這麼簡單，而是需要策略和方式，尤其對新手而言，除了選股以外還會遇到語言、開戶流程、Ap
API（Application Programming Interface，應用程式介面）可以視為不同軟體系統之間的溝通橋梁，讓雙邊可以交換數據並執行各種功能。這篇會記錄產品經理一定要知道的幾個 API 概念，像是常見的錯誤代碼以及不同的 HTTP 方法（如 PUT、GET、POST）和實際案例說明
雲端已經成為App開發的核心，而Amazon的AWS（Amazon Web Services是開發者常用的平台，可以幫助開發者建立、整合和擴展App。
為何很多公司很怕Amazon？
亞馬遜有大筆資金可以侵入其它公司的專業領域
擁有電商平台、Alexa助理，進而可以搶走Google search或其他網站上搜索流量然後掌握顧客數據
亞馬遜本質上不是一家電商或科技公司，他是一家基礎設施（雲端計算、物流）公司所以具有強大的核心競爭力
Amazo
當我們在開發一個AI應用服務時， 常常會需要載入大模型， But… 我們總不可能每一次的請求就載入一次模型吧！ 這樣太沒有效率了， 也非常的浪費資源， 因此我們通常會希望應用程式啟動時就能夠載入模型， 之後每一次的請求只要讓模型進行運算即可， 那麼在FastAPI的框架中究竟要如何使用呢？
首
※ 什麼是 RESTful API？
這種運用 HTTP 來表達語義的路由設計風格稱為 RESTful API，它描述了如何實現 Web API 的架構。所謂的 API 是應用程式介面 (application programming interface)，網址也是一種應用程式的「介面」，故稱為
當我們在撰寫一套系統的時候， 總是會提供一個介面讓使用者來觸發功能模組並回傳使用者所需的請求， 而傳統的安裝包模式總是太侷限， 需要個別主機獨立安裝， 相當繁瑣， 但隨著時代的演進與互聯網的崛起， 大部分的工作都可以藉由網頁端、裝置端來觸發， 而伺服端則是負責接收指令、運算與回傳結果， 雲端
這篇內容精華重點：一個是 Open AI 執行長分享了一篇「希望有人早點告訴他的幾件事」，從過來人的角度分享他年輕時會希望有人告訴他的事情，很有啟發，還有一部影片是我認為人生必看 TED 的演講，叫脆弱的力量，告訴我們與脆弱相處的方法跟重要性。
Webhook 提供一個「即時觸發」的資料傳送方式。Webhook 與 API 的差異及在自動化流程中的作用是什麼？它讓你在事件發生時獲得通知。透過生活化的情境舉例，理解 Webhook 的運作原理，並了解如何透過 No Code 自動化工具設定 Webhook，實現自動化整合，提升工作效率！
先前幾篇筆記介紹了網路請求，瀏覽器儲存資料的方式，那麼實務上，前端最常需要發送網路請求的時候，就是透過呼叫 API，去向後端工程師發送/請求資料，所以今天來記錄什麼是 API吧！
在沒有分環境之前，每一隻lambda只有一個code console給所有人一起編輯，開發好了就deploy，根據設定的trigger觸發執行。
現在我們希望能夠在code console開發，然後deploy到不同的stage，目標是不同stage的api gateway能夠調用該lambda的