成人午夜在线播放,亚洲精品一区二区三区www,特级毛片免费观看视频

API 上下游關聯方

一致性與可重用性：API 設計為在不同項目和應用中具有一致性和可重用性。這使得標準化變得簡單，減少了開發時間，提升了解決方案的可擴展性。
協作與文檔：API 優先的方法強調開發團隊、業務利益相關者和外部合作伙伴之間的協作。全面的文檔對于確保每個人了解如何有效使用 API 至關重要。
測試驅動開發：從一開始就對 API 進行嚴格的測試，以便在開發過程中盡早識別和解決問題。這有助于保持高質量標準，并降低后期出現昂貴錯誤的風險。

從上述準則中我們可以看到，基本上貫穿了 API 生命周期的大部分，也對我們設計、開發 API 提出了一定的要求，那么遵循 API First 可以給我們帶來哪些好處？

提供更好的開發體驗：設計完善的 API 和詳盡的文檔，使開發者更容易理解和實現，降低溝通成本。
提升開發協作的效率：可以先通過 API 接口描述以及 API Mock 能力進行快速開發協同，測試可以提前準備測試用例，同時前端也可以基于 API 接口以及 Mock 數據完成頁面的開發，此時后端的業務接口可以同步進行開發。另外，不同的微服務開發團隊之間可以基于 API 展開工作，多個開發團隊可以并行工作在應用的不同組件上，顯著加速整個開發流程。

通過提供 API 接口使得多個團隊協同開發進度不會互相 Block。

靈活性和易集成性：具備一致性與可重用性的 API 可以使業務可以更加快速適應不斷變化的市場需求，具備一定的可擴展性；憑借核心的 API，使得與第三方服務、平臺和應用的集成變得更加流暢，促進了更加連貫和整合的生態系統。電商、車企基于 API 構建能力開放平臺，通過 API 降低生態間集成的成本。
自動化與創新：在一定的管控下通過 API 透出完整的操作以及數據，在此之上可以構建出更多自動化的工具提升企業的效率，可以基于 API 構建完善的 Devops 能力?？梢哉f API 是自動化的基石，也是創新的基礎。
安全：在 API 設計階段考慮安全需求，通過 API 安全能力更早地進行安全設計與防護；接口的標準化與一致性有助于統一安全策略的實施與難度。由于 API 限定了服務提供能力的范圍與邊界，這幫助團隊嚴格控制每個接口可以訪問的功能和數據，支持安全的最小權限原則，減少數據泄露的風險。

阿里云上 API First 實踐

基于 API 網關策略場景，談 API First 實踐。

API 網關存在非常多策略規則

在云原生 API 網關的使用和管理中，存在大量不同類型的策略規則，這些規則主要集中在安全能力、流量治理能力管理和 API/接口策略方面。為了有效管理這些策略，我們設計了一種通用的方式來抽象這些規則，并能夠靈活地應用到不同的實體（如網關、路由、服務、域名）上。

設計 API

我們的解決方案基于兩個主要模型：Policy（策略）模型和 PolicyAttachment（策略附加）模型。Policy 模型負責定義所有策略的細節和規則，通過這個模型可以對策略進行增、刪、改、查等操作，確保靈活性和可管理性。

API 網關策略管理能力模型設計

策略類型包括 IP 黑白名單、消費者鑒權和全局鑒權等安全能力管理，以及超時限制、重試機制、跨域資源共享 (CORS) 和重定向等 API/接口策略。下面是其中一個策略的示例：

{  "policyId": "policy1",  "name": "IP 黑名單策略",  "description": "禁止來自特定 IP 地址的訪問",  "type": "security",  "rules": {    "blacklist": ["192.168.1.1", "10.0.0.1"]  }}

為了將這些策略有效地應用到特定的實體中，我們引入了 PolicyAttachment 模型。PolicyAttachment 模型用于將已經定義的策略綁定到特定的實體（如網關、路由、服務、域名）上，使得同一策略可以在不同的上下文和場景中應用，從而提供了更高的復用性和管理效率。下方展示了將策略綁定到一個服務的示例：

{  "attachmentId": "attachment1",  "policyId": "policy1",  "entityType": "service",  "entityId": "serviceA"}

為了管理策略和綁定關系這兩個模型，我們設計了一套 RESTful 風格的 API 接口。這些接口涵蓋創建、獲取、更新和刪除策略的所有操作，以及附加和移除策略的功能。例如，一個 IP 黑名單策略的 Policy 結構如下：

{  "name": "IPBlacklist",  "type": "security",  "rules": {    "blacklist": ["192.168.1.1", "10.0.0.2"]  }}

并且將該策略附加到一個 API 網關的請求如下：

POST /api/policyContent-Type: application/json

{  "name": "IPBlacklist",  "description": "gateway",  "config": {    "name": "IPBlacklist",    "type": "security",    "rules": {      "blacklist": ["192.168.1.1", "10.0.0.2"]    }  },  "attachResourceIds":[    "gatewayId1",  ],  "attachResourceType": "Gateway",  "environmentId": "environmentId1",  "gatewayId": "gatewayId1"}

通過這種統一的策略管理系統，我們不僅能夠提高系統的靈活性和可擴展性，還使得安全性和管理變得更加高效。

基于上述思路我們提供了 API 網關最基本的策略相關的 API 接口設計思路。

在 API 網關中構建 API

OpenAPI Specification (OAS) 是一種用于定義和描述 RESTful API 的標準化格式。以下是基于 OAS 定義的策略管理 API 模型：

openapi: 3.0.0info:  title: Policy Management API  version: v1servers:  - url: /apipaths:  /policies/{policyId}:    get:      summary: Get details of a specific policy.      operationId: getPolicy      parameters:        - name: policyId          in: path          required: true          description: The ID of the policy to retrieve.          schema:            type: string      responses:        '200':          description: Successful response with the policy details.          content:            application/json:              schema:                $ref: '#/components/schemas/Policy'components:  schemas:    Policy:      type: object      properties:        id:          type: string        name:          type: string        description:          type: string        createdAt:          type: string          format: date-time        updatedAt:          type: string          format: date-time

設計好 Policy 相關的 API 后，我們需要一個完整的 API 生命周期管理能力來幫助我們實踐 API First。我們以阿里云的云原生 API 網關為例，實踐整個 API First 的開發模式。

我們可以看到云原生 API 網關中，API 是整個產品的第一公民，與 API First 的開發原則顯得異曲同工。首先先創建 PolicyManagementAPI。在創建的過程中我們看到，支持 OAS/Sawgger 等標準導入 API，也支持手動創建整個流程。我們先看看手動錄入的效果。

云原生 API 網關控制臺創建 API

創建完成 API 之后，產品會引導我們去創建接口。關于 Policy 相關的接口我們計劃創建關于 Policy 資源操作的生命周期增（創建策略并關聯資源）、刪（刪除策略并取消關聯資源）、改（修改策略并重新關聯資源）、查（查詢策略）。

云原生 API 網關控制臺創建 API 接口

我們提前設計好了 API ，因此創建接口的過程中，只需要按照我們的設計填入 API 接口的 Metadata 即可。

在 API First 原則中，文檔也是不可或缺的一部分，每次修改接口對應的接口文檔也需要同步更新，既然我們在 API 管理平臺上完整錄入了接口的元數據信息，那么相關的文檔、SDK、spec都應該實時更新。下面我們看到，比如請求參數的 Body 信息，其中 JSON Scheme 是用于 API 接口文檔的詳細內容生成。如果我們不填寫，后續文檔的可讀性會大大降低，但我們也發現這個內容其實非常重復性且標準化，所以 API 網關提供了 API 輔助生成 Schema 的能力。

云原生 API 網關控制臺創建 API 接口

填寫完成所有的內容后，點擊添加。我們逐一錄入所有的接口，當前 API 完整的情況如下圖所示。

云原生 API 網關控制臺 API 詳情

我們下載 SDK&文檔看一下，提前設計好 API (API First) 是如何幫助我們加速開發流程以及提升開發體驗。

云原生 API 網關控制臺生成 API SDK 與文檔

選擇 Java SDK 看看生成的效果。

API 文檔

由于后端還沒有編寫，目前不能直接調試。但是協作方可以基于此進行開發。

我們可以構建 API Mocking，這樣可以更加方便協作方進行開發調試。

API Mocking

在開發 API 邏輯之前，通過 API Mocking 提供初步的接口模擬，這有助于進行早期的驗證和測試。提升開發聯調效率。在 API 網關中進行該操作只需要 2 步，先定義 API 接口 Mock 返回的內容，再發布 Mock 服務即可。

API 網關控制臺配置 API Mock

API 網關控制臺發布 API Mock

發布完成后，我們直接在 API 網關頁面進行在線調試。

API 網關控制臺調試 API

我們在 API 文檔中找到需要的接口并且直接進行調試，也返回預期的 Mock 值。這樣可以大幅度提升協作開發的效率。

通過 API 文檔調試 Mock 的 API

有了 API Mocking，前端、后端、 QA 以及其他依賴的業務方團隊都可以同時進行工作，構建測試、客戶端應用和服務器實現。

實現 API 邏輯

我們可以將 spec 以 OAS3.0 格式導出，并通過 Swagger Codegen 可以快速生成服務端的代碼框架，幫助我們加速開發的效率。

Swagger Codegen 介紹

另一方面我們需要實現 API 邏輯，并將其與后端系統集成。遵循編碼、安全和性能優化的最佳實踐。在這邊我們不過多贅述。

API 測試和驗證

當我們 API 開發完成后，我們可以先將后端發布至測試環境，并將 Mock 服務切換至真實測試環境后端服務。協同 QA、前端、依賴方進行完整的測試驗證。包括但不限于進行功能、性能和安全測試，以確保 API 達到質量標準。

為了方便測試集成，我們需要對我們的 API 配置自動化的測試工具，集成到我們的測試體系中，可以做到常態化驗證保證 API 接口的正確性、性能和安全性。

我們還需要針對 API 配置安全防護策略，根據我們 API 的性能表現配置流量防護等限流策略，配置安全鑒權認證規則，并完成完整策略能力驗證。

配置合適的流量防護策略

可以給當前 API 授權給不同的消費者去訪問

完成這些準備工作后，我們就可以對 API 進行發布部署上線的流程。

API 策略配置

在 API 管理生命周期中，API 的安全性以及流量防護策略配置也是非常重要的一環。API 不僅是系統與系統之間的通信入口，還是安全和流量防護的第一道防線。阿里云 API 網關（API Gateway）提供了非常豐富的插件、策略能力，可以低成本幫助我們 API 做到完善安全防護以及系統防護能力，保證 API 的穩定性。

云原生 API 網關在安全防護領域的插件

設置黑白名單：設置黑白名單可以通過在 API 上配置特定的黑名單和白名單，有效地控制訪問請求的權限。插件支持在網關全局、域名以及路由級別進行 IP 黑名單和白名單的配置，比如我們能夠拒絕或允許特定 IP 的訪問請求，靈活的配置策略滿足對不同場景下 API 的訪問控制的精細化需求。

云原生 API 網關在認證鑒權領域的插件

細粒度權限控制：在 API 上實施細粒度的權限控制，確保用戶只能訪問其權限范圍內的資源。云原生 API 網關支持全局認證、路由配置認證和消費者鑒權，實現對 API 訪問的控制、安全性保障和策略管理。下方展示了云原生 API 網關在認證鑒權領域的插件。

云原生 API 網關豐富的策略能力

精細化流量防護能力：云原生 API 網關支持 API/接口級別進行流量控制、并發控制策略，通過對 API 和接口級別進行精細化流控，可以有效管理和監控請求流量，從而防止因突發流量或惡意訪問導致的系統過載。這種精細化管理不僅可以限制單個用戶的請求頻率，保護后端服務的性能，還能根據實際負載動態調整策略，優化資源分配，確保 API 服務在高并發場景下依然能夠平穩運行。

API 發布、部署與監控

API 網關在發布部署的過程中提供了灰度發布、全鏈路灰度的能力，可以幫助我們在發布的過程中控制風險與影響面。API 的發布過程，我們可以通過 CI/CD 集成的方式實現進一步的自動化。云原生 API 網關默認內置了云監控、Prometheus 等監控、可觀測能力，可以幫助我們觀測 API 在生產環節中的性能和使用情況。我們可以通過監控、告警來保障我們 API 的穩定性，持續滿足業務的SLA需求。

API First 的實踐理念強調在軟件開發過程中，優先設計和考慮 API 的需求，以確保系統的靈活性、可維護性和可擴展性。這一理念貫穿了需求設計、協同開發、上線和運維等全生命周期。

云原生 API 網關可以幫助我們更好地實踐 API First。

在需求設計階段，API First 方法鼓勵團隊在早期就明確 API 的功能和接口契約，通過文檔化的形式確保各方對于 API 的理解一致。這種自上而下的設計思路能夠有效減少后續開發中的溝通成本和誤解，從而提高開發效率。
在協同開發過程中，云原生 API 網關發揮著關鍵作用。它不僅提供了統一的接口管理，還可以根據 API 的定義，自動生成 SDK 和文檔，方便開發人員快速上手。通過 API 網關，團隊可以實現快速構建、發布和迭代，支持微服務架構的靈活性，使開發人員可以專注于業務邏輯的實現而非底層細節。
上線階段，API 網關能夠幫助我們進行流量管理和安全控制，確保 API 在生產環境中的穩定性。例如，通過流量監控和限流策略，及時發現和處理異常流量，保障用戶體驗。同時，API 網關可以集成身份驗證和授權機制，進一步增強 API 的安全性。
在運維環節，云原生 API 網關提供了豐富的監控和分析功能，幫助運維團隊實時評估 API 的性能和健康狀況。通過分析 API 的訪問日志和使用數據，運維人員能夠快速定位問題，優化系統性能，保證服務的高可用性。

API 設計建設

下面我們基于 API 網關開發過程中的一些生產實踐經驗談一談關于 API 設計的建議。

可演進性

API 設計中提供了版本的概念，對于同一個版本的 API 來說，每一次 API 變更都需要考慮到 API 的向前兼容性，即老的客戶端能否正常訪問服務端的新版本也不應該有錯誤的行為。

新增可選字段
不應該刪除、修改已有的方法、字段、枚舉值
API 接口沒改的前提下，不可以擅自改變 API 語義

任何一次API的升級，我們都需要考慮已經使用 API 的用戶，他們的業務是否會因為我們的一次變更而出現不兼容的風險。

如果存在不兼容的變更，我們需要通過升級 API 的大版本來實現，這時候會涉及到客戶端的升級，那么這個過程將會是非常漫長，頻繁的不兼容升級對我們的 API 使用者來說是一件不愿意接受的事情。也正是因為如此，反過來說，我們才從一開始就重要 API 的設計。在 API 設計的過程中，可以多驗證自己的 API 設計，在發布前提前挖掘潛在的風險。

關于軟件升級與變更，在 OpenAPI 規范中，可以以描述的形式在基本信息中指定本 API 的版本。我們可以通過標準的版本控制方法允許引入新功能或者重大變更的過程中保證 API 的穩定性，從而確?，F有用戶和客戶端應用不會受到突然的變化影響。這種向后兼容性對于維護長期用戶信任和應用的連續性至關重要。另外，API 的版本控制幫助我們給 API 使用者提供一條平滑的升級路徑，使得開發者和用戶可以按照 API 維度逐步遷移至新版本，避免一次性全面升級的風險。

好的 API 文檔

在如今微服務架構日益普及的環境下，一個服務會依賴大量的外部 API 接口，在開發的過程中 API 文檔的重要性不容忽視。準確而及時更新的 API 文檔能夠為開發者提供清晰的接口說明和代碼示例，這樣會大大減少了誤用和踩坑的幾率。同時，它顯著提高了開發效率，通過減少溝通成本和快速解決問題來支持敏捷開發和快速迭代。

JDK ArrayList 文檔

這也是為什么一個好的 API 可以經久不衰的原因之一。我們可以從上述示例中看大，一個好的 API 文檔會描述 API 的功能、實現、例子，同時也會提到使用該 API 需要注意的點，可能會有哪些風險 Note that this implementation is not synchronized. 這些都可以幫助使用者提前識別該 API 適用的場景。

控制 API 的數量

當一個產品涉及數千個 API 時，其使用者和維護者所面臨的成本都會顯著增加。最初花費幾個小時實現的 API，可能最終需要投入數百甚至數千小時進行維護和升級。因此，對于我們內部開發而言，每新增一個 API 都必須經過嚴格的評審。我們盡量在初期通過精心的 API 設計和已有 API 的組合，來滿足新的 API 使用場景。因為一旦 API 開放，就有用戶和客戶端開始集成，這意味著 API 的收斂、下線以及變更將成為一項巨大的負擔。

再談 API First 的得與失

API First 對于效率是降低還是提升？由于 API First 模式在程序設計初期就需要集中精力進行 API 設計，因此需要較為全面的前期規劃和設計工作。此外，提前做出 API 設計決策可能會限制開發過程中的一些嘗試與探索，可能在開發后期需要進一步調整 API 的設計，當 API 數量大了之后這整個過程會在一定程度上減慢項目開發的速度，API 的設計、管理與維護都有一定的負擔。

一旦設計并確定了明確的 API 后，可以促進并行開發，減少依賴性和瓶頸，從而加快功能交付速度。一個完善的 API 管理工具也能夠有效降低 API 管理成本。在項目的后期，包括上線后的產品體驗，使用 API First 開發模式都會有更多的益處：明確的 API 使得外部系統和第三方應用的集成更加輕松，通過工具建設提升效率；一開始就考慮可擴展性和安全設計，使系統具備更強的安全、高可用能力；通過 API 暴露出來的數據也會激發工程師和用戶的創新。因此，盡管前期開發速度可能受到一定影響，API First 模式在長期來看能夠顯著提升項目整體效率和產品質量。

在 AI、小程序、Serverless 等軟件技術快速發展的趨勢下，API First 開發模式使應用程序能夠更靈活地與這些技術進行集成。通過 API，無論是與 AI 服務交互，還是與小程序和函數計算通信都能迅速實現。這不僅加快了探索和上線的速度，也降低了業務試錯的成本，為公司在快速變化的市場中保持競爭優勢提供了有力支持。

文章轉載自： 基于 API 網關踐行 API First 開發實踐