API優先（API-first）是一個壞主意！ - stilkov

banq發表於2020-09-11
API

許多企業IT部門已成為“ API優先”策略的忠實擁護者。我認為總的來說，這是一個壞主意。
當您開始使用API​​時，您必須非常瞭解API使用使用者的需求。API優先則可能導致你不會這樣做，取而代之的是，您嘗試提出“顯然”可以重用的東西，最後得到甚至沒有用的東西。
最常見的是，API受其封裝的基礎系統功能的影響，如果這些封裝很棒，那就太好了，但通常不是。
API優先策略的假設前提是：透過“僅僅編排”API公開的功能來構建出色的應用程式。對於某些應用程式是正確的，但對於許多應用程式卻不是，通常對於出色的應用程式而言並非如此。
除非API是您提供給外部客戶的實際產品，否則透過在終端使用者和業務邏輯之間放置API邊界（以及由此產生的Conway法則影響）而建立的人為鴻溝會帶來很多痛苦，並且幾乎沒有價值。
在許多情況下，以API為中心的策略標誌著戰略者不希望面對實際的終端使用者及其需求。建立其他人必須組裝的可重用服務要容易得多，甚至為此建立元策略也要容易得多。
我將現代企業IT戰略中的大部分災難歸咎於這樣的事實，就是像我這樣的人：後端架構師對UI / UX方面的關注太少了，因為這些架構師被控制得太久了。
您需要一種用於模組化應用程式交付的策略，不僅要包括終端使用者的需求，還要從終端使用者的需求開始。API是達到此目的的一種有意義的手段。
如果您將API作為產品（例如，作為SaaS提供程式）提供，則將開發人員視為終端使用者。如果不是這種情況，那麼：您的終端使用者不在乎API，因此您不應將它們放在中心地位。
 
眾說紛紜：
完全同意。我從事付款工作。我們引入了一套付款API，在引入ux / ui時的第一個試驗就完全失敗了。使用者要做的第一件事是驗證帳號，但API不能驗證帳號。
 
如果您曾經遇到過《 Hyrum定律》中提到的問題，那麼API優先甚至意義不大：/->合同中的承諾無關緊要，系統中所有可觀察到的行為都將取決於某人。 https://hyrumslaw.com
 
我一直相信客戶會推動API的發展。一切都是由客戶端的驅動來詢問客戶。自下而上的設計很容易出錯。
 
IT無法構建滿足需求/期望結果的東西並不是什麼新鮮事。工具，技術和體系結構發生了變化，但問題仍然令人沮喪。
 
所有內容都是正確的。但是，我遇到的許多API-First練習者都是與利益相關者共享模擬，並儘可能早地模擬現實世界實現中發生的一切。不確定為什麼API-First意味著沒有UI /終端使用者參與嗎？
 
我對“ api優先”的思考方式更多地是“ api消費者優先”。api必須說出消費者的語言，並滿足消費者的需求。這與自下而上的設計形成鮮明對比，後者在後端定義了資料模型和粒度。
 
基於實體的CRUD服務應遵循標準模式。查詢方面需要針對用例進行定製，以便消費者可以輕鬆訪問需要的資料。簡介：構建支援您的用例的API，而不是後端服務可以提供的API。
 
大多數企業並未意識到..必須關注使用者和使用者需求，什麼時候構建或什麼時候不構建基於API的生態系統？這種區分對待是很重要的。
 
banq評：這也是體現DDD和物件導向不同之處，物件導向重在封裝和重用，但是如果沒有上下文，這種封裝和重用可能是短視的，只從封裝和重用角度設計API，這種API優先設計法肯定會有問題。DDD和OO是有區別的：抽象名稱選擇很重要？
DDD+微服務==>API，將業務領域的能力共享給消費者，消費者可以根據UI/UX要求組合有選擇性的使用這些能力，API沒有提供的功能表示其能力有限，或超過其能力範圍。

相關文章