下面將通過幾個關鍵詞的形式說明API管理的重要性和未來的實現方式。

1.生命週期管理

• 在整個API生命週期中更深入地整合所有工具將進一步提高生命週期迴圈的速度，而且更重要的是提供滿足消費者需求的API。這與API生命週期中的流程改進密切相關，我們看到這種情況越來越多發生在各個產品，因為更多企業開始將API視為產品經理指導生命週期的產品。

• API是我們更快地構建軟體的核心，使用微服務和驅動CI / CD環境與Kubernetes（K8s）進行通訊。隨著公司採用無伺服器架構，通過API呼叫執行越來越多的程式碼和業務邏輯，這將變得更加重要。各種規模的企業面臨的主要問題是：如何以不犧牲效能和成本的方式管理API的整個生命週期？否則，企業將只看到他們的成本將隨著他們的新數字業務產品的成功而成比例地增加，從而損害長期可持續性。

• 分散式API管理是大規模分佈的現代應用程式開發的本質。必須分發API管理。允許使用單一窗格集中控制服務，所有報告都顯示誰可以訪問哪些內容，哪些服務可用，以及這些服務的自動化位置。任何與應用程式本身不一致的事情都會在某些時候與你的集中管理層產生不同步的情況。具有本地化控制和分散式執行，每個服務都會向服務中心報告。當有人試圖訪問服務時，它可以命中集中認證伺服器以確定該人是否應該具有訪問許可權。

2.應用程式的整合

• 我們主要關注的是使用API​​來跨應用程式和業務合作伙伴進行整合。企業內部通過使用SaaS應用程式替換舊系統來實現IT系統的網際網路化，這些新應用程式需要與其他企業系統整合，無論是網際網路還是傳統企業。例如，經常與實現ERP系統化的客戶合作，那就需要將新ERP與其他系統整合。多一個遺留系統可能會導致基於檔案的整合混亂。

• 使用新的ERP或者已釋出的API管理系統是連線所有其他企業系統（如總帳和倉庫管理解決方案）的首選整合點。此外，這些系統化的ERP解決方案能夠通過其API提供對企業資訊的實時訪問。

• 能夠與客戶合作，利用向其合作伙伴釋出API，從而提供對此資訊的有限訪問許可權。例如，想要檢查庫存或檢查訂單狀態的合作伙伴可以使用API​​直接從ERP提供其資料檢視，這可以通過API查詢來增強傳統的EDI流程，以便對從實時響應中受益的某些行為進行查詢。

3.微服務

• 如今每個人都曾經談論過API生命週期，但很多時候你只會為每個開發階段提供工具，而不是提供一種整合方法，使開發人員能夠更輕鬆地設計，實施，部署並以自動方式管理它。如果設計文件，需要等待數月才能看出API是否符合設計要求，那實在是一個很低效的流程。一個開發人員更希望迭代方便並支援敏捷開發過程。我們最終會走上自動化API的DevOps的道路，即便我們現在還沒有到那個時候。

• 隨著未來出現多種形式因素的控制點型別。考慮服務網路和API管理將如何疊加是很重要的，API管理是關於提供服務與該服務的多個消費者之間的關係。規模越大，正式的API管理平臺就越重要。國內的話可以使用 EOLINKER API Studio 平臺 ，國外的話可以考慮Swagger\Postman等等。

• 如果使用API​​而不是共享庫來控制單個使用者或開發人員團隊的API訪問，則服務網路可以很好地保護兩個端點之間的通訊。服務網格提供智慧網路，以幫助開發人員連線網格中的其他服務。開發人員在學習如何建立在容器、微服務環境和服務網路上工作的分散式應用程式的基礎上，將反過來幫助開發人員解決這個問題。

• 基於微服務架構的應用程式現代化是數字化轉型計劃的核心。最大的機會在於微服務的API管理。對於管理微服務使用的API，需要具有靈活、可移植且可在任何基礎設施（裸機，VM和容器，公共雲和私有云）上執行的“小佔地面積”的解決方案。

• 可以預見的是，在未來的一兩年內，服務網路將出現巨大的趨勢，更多企業會採用API管理並帶給每個微服務，以確保應用程式和微服務相互通訊的能力。而不是API閘道器也將代理放在邊緣以欺騙微服務，用以僅與代理進行通訊。

• 市場已經為SaaS解決方案做好了準備，能夠將微服務API直接給客戶提供使用授權和API交付選項。舉個例子，亞馬遜將AWS的每個元件構建為可由客戶直接定址的微服務，而且可以編寫接收OAuth承載令牌的自定義授權者，並根據IAM策略將這些授權者轉換為訪問決策。這實際上很簡單，雖然它需要AWS客戶的大量配置和定製。當市場需求足夠大，總有一天我們會看到亞馬遜提供的基於標準，資源感知的API身份驗證和授權產品作為一流的命名產品提供，而不是隱藏在教程中的業務流程。

4.API其他技術

• 更多關於API管理的工具會在市場上出現，整合度將會越來越高，它代表著這個行業的成熟。使用一系列合適的API工具來完成特定的工作並且做得很好，這無疑是最高效率的，也為開發人員提供空間，使他們可以專注於他們的核心專案，並將冗餘工作委託給已經完善的服務，以確保質量和效率。

• 只要遵循“更小，更高效，支援多語言”，通訊方式在內部和外部使用的樣式可以更多樣。比如，GRPC是由Google開發的二進位制格式，是一種更有效的內部通訊方式。但在外部，仍然需要像REST那樣對使用者友好的東西，因此為了方便，內部更多地採用GRPC和API。我們將看到以多種格式呈現的API，一種是內部格式，另一種是外部格式。

• 從短期來看，HTTP很可能會在API的形式上產生比目前更廣泛的影響。無法實現的用例，現在可以實現傳統的通訊模式。從長遠來看，真正的資料（可能是計算）分散可能會嚴重改變流程。但是，實現這一概念的工具仍然處於起步階段。今天最先進的推動者是區塊鏈正規化，看到很多公司正在探索區塊鏈如何解決這些問題，也許在未來所有的問題有的新的解決的思路。

• 雖然與RESTful API相比，OpenAPI規範（OAS 3.0）的採用率仍然很高，但一些公司和技術正在採用超越SOAP / XML和基於WSDL / WADL的API。基於HTTP / JSON的RESTful API等技術的新進展正在被採用，併為行業提供了很好的服務。

• 此外，非基於HTTP的API也在不斷增加，使得gRPC，非同步API（訊息傳遞，流媒體，釋出和訂閱）成為一些公司關注的焦點。例如，構建AsyncAPI規範是為了解決基於非HTTP的非同步API，如MQTT，Kafka，WebSockets，AMQP和STOMP協議。這就是API管理供應商興起所在，這是一種將API規範從一種格式轉換為另一種格式的工具。

• API管理供應商的另一個機會是擴充套件API操作（APIOps）中的產品。APIOps將以與將DevOps應用於軟體開發生命週期類似的方式應用於API。例如，GitLab為API生命週期提供完整的DevOps工具，從專案規劃，原始碼儲存庫到CI / CD監控，安全性，問題跟蹤功能，可以在同個地方提供給企業。以上所有內容都可以隱藏在API管理平臺後實現。

• 考慮到成本未用於正確維護API時所產生的成本或安全問題，我們需要更好的方法。GraphQL，SPARQL和與資料共存的資料安全性提供了一個有吸引力的未來。它不僅簡化了，還提供了額外的實用程式，並將資料安全性放在了首要關注的位置。區塊鏈可用於保護資料完整性，允許消費者證明資訊的來源。

• 將來，大部分資料都將實時生成，傳送和接收。鑑於每天生成的資料量正在以極高的速度增長，開發人員將很快需要更多的雲原生和可擴充套件的解決方案來管理API。舊版API管理解決方案已經太慢，並不總是能夠橫向擴充套件。

5.典型的實踐

API管理工具能提供一套產品來幫助企業大規模管理其API設計工作流程。其中一個關鍵部分是構建在大多數企業中已存在的開發工作流程上，這意味著與GitHub等現有工具整合。為此，好的API管理工具需要能進行API整合，自動將GitHub中的資訊提取到產品中，並將資訊從產品推送到GitHub。最終結果是為我們的客戶提供了更好的體驗，並且由於GitHub公開的豐富API而使其成為可能。API解決的基本問題是，在最短的時間內以最小的成本解決技術需求。市場上比較好的API管理工具有POSTMAN（英語）、EOLINKER（中英）、Swagger（英語）等。

史基浦機場啟動了一個用例，改善了通過機場的乘客體驗。有太多的資料是有價值的，它成了一個整合問題，擴充套件登機牌，跟蹤航班，到達離境資訊，飛行員警報等資訊整合，以實現內部敏捷性，他們決定以API為重點，努力實現不同應用程式的整合，開啟內部API以構建合作伙伴生態系統。

Capital One是全球最大的銀行機構之一，提供各種線上金融服務，包括API產品。第三方開發商和合作夥伴可以為其客戶提供一流的數字體驗，並通過使用Capital One的外部API開啟銀行賬戶，生成個性化信用卡優惠以及跟蹤客戶獎勵來創造新的收入來源。NGINX技術使Capital One能夠將其應用程式擴充套件到每天120億次操作，峰值為每秒200萬次操作，延遲時間僅為10-30毫秒。

還有一個典型的用例是Netflix，他們需要連線超過500個客戶端裝置，iPhone，Android，X-Box等。但它們具有良好規範化的API，可以處理電影中的元資料，處理搜尋請求，影象服務，電影的實際流式傳輸。但是在緊張的網路上受限制的裝置，他們為前端（BFF）建立了一箇中間件後端來使用基礎API，包含客戶端需要使用的大部分業務邏輯，然後開啟自己的API的介面，這些API只為該客戶端提供服務。當一個新的客戶端出現時，他們所要做的就是在客戶端程式碼中建立一個新的BFF。如果不再需要一個裝置的客戶端，它們只會關閉該程式碼並且不會破壞任何內容。

如果是營銷人員或是營銷技術公司，他們過去常在內部構建軟體解決方案。然而，主要問題是獲取構建可銷售產品所需的資料需要大量的時間和金錢。營銷需要大量資料才能有效，但收集和分析所有這些資料的成本非常高，而且因為很明顯並非每家公司都能夠分配所需的資源來實現軟體專案，因此進入市場的技術門檻是不合理的。而現在運用API技術可以在幾周內構建一個簡單的關鍵字研究工具，大大提高了營銷的效率。

參考資料：

https://dzone.com/articles/api-management-additional-considerations

https://dzone.com/articles/api-use-cases-1<