14個文本轉圖像AI API
你可能也喜歡這些API文章!
標記為 的操作CreateQuote向 API 使用者表明，他們可以根據響應使用該操作執行交易CreateTrade。客戶端必須從響應中檢索 的值quoteId并使用它來填充請求正文。
此示例展示了 API 提供商如何使用 OpenAPI 描述請求之間的鏈接信息，當使用屬性實現時operationRef，它可以在不同的OpenAPI 文檔之間建立橋梁。提供此信息是一項非常強大的功能，因為它消除了 API 使用者的猜測，他們可以利用工具自動鏈接請求。
然而，有時描述來自不同提供商的 API 之間的鏈接是有意義的。這就是 OAI 工作流可以提供幫助的地方。
正如我們已經說過的，在平臺由各個部分組成并集成許多不同系統以提供特定功能的環境中，跨 API 鏈接是一個共同目標。軟件開發人員通常必須弄清楚如何以正確的順序進行 API 調用，并在調用之間傳遞正確的上下文。
雖然這對于簡單的 API 來說是可以接受的，但更大、更復雜的序列要求更高，并且可能導致對 API 提供商的支持要求復雜。這就是 OAI 工作流特別興趣小組 (SIG) 試圖通過工作流規范填補這一空白的地方。此規范的理念是提供一份人類和機器都能理解的描述文檔，使它們能夠無縫地將一系列事件編織在一起。
給定的工作流文檔旨在以 API 使用者選擇的方式實現（與 BPEL 示例不同），使用他們自己選擇的計算和軟件。這為 API 使用者在實現方面提供了相當大的“優勢”，同時又不損害他們對如何協調多個 API 請求的控制權。
以規范中的示例（基于登錄Petstore API 的工作流）為例，工作流提供程序首先描述并唯一標識工作流。在此定義中，它們指定工作流的外部輸入，在本例中username為 和password：
workflows:
- workflowId: loginUserAndRetrievePet
summary: Login User and then retrieve pets
description: This workflow lays out the steps to login a user and then retrieve pets
inputs:
type: object
properties:
username:
type: string
password:
type: string然后，工作流提供程序概述了工作流中的步驟（在示例中，后面loginStep跟著getPetStep），使用運行時表達式提供對輸入值和要在步驟之間重用的值的引用。例如，username使用表達式引用輸入$inputs.username：
steps:
- stepId: loginStep
description: This step demonstrates the user login step
operationId: loginUser
parameters:
# parameters to inject into the loginUser operation (parameter name must be resolvable at the referenced operation and the value is determined using {expression} syntax)
- name: username
in: query
value: $inputs.username
- name: password
in: query
value: $inputs.password
successCriteria:
# assertions to determine step was successful
- condition: $statusCode == 200
outputs:
# outputs from this step
tokenExpires: $response.header.X-Expires-After
rateLimit: $response.header.X-Rate-Limit
sessionToken: $response.body
- stepId: getPetStep
description: retrieve a pet by status from the GET pets endpoint
operationRef: https://github.com/swagger-api/swagger-petstore/blob/master/src/main/resources/openapi.yaml#/paths/~1pet~1findByStatus/get
dependsOn: loginStep
parameters:
- name: status
in: query
value: 'available'
- name: Authorization
in: header
value: $steps.loginUser.outputs.sessionToken
successCriteria:
- condition: $statusCode == 200
outputs:
# outputs from this step
availablePets: $response.body
outputs:
available: $steps.getPetStep.availablePets這些步驟還提供了成功標準，讓工作流消費者了解在他們的代碼中需要注意什么、依賴關系以及每個步驟的輸出，這些輸出稍后可以使用。
當您考慮使用 Workflow文檔幫助 API 使用者實現與多個 API 的集成時，Workflow 規范的優勢便會立即顯現出來。不過，API 市場中的發布者也有可能利用 Workflow 文檔，將來自不同提供商的多個獨立 API 的 API 調用序列編織在一起。因此，Workflow 用例雖然并不一定是新的，但具有極大的潛力，可以簡化 API 使用者的 API 使用，同時仍允許他們控制使用 API 的方式。
上述示例只是開發人員可以用來鏈接 API 請求的工具的一小部分。在本文中，我們重點介紹了在設計時進行鏈接以及通過規范文檔提供排序信息。不過，開發人員可能會根據他們選擇的編程語言或他們所在組織提供的平臺使用其他工具。
然而，OpenAPI 和 OAI 工作流中的鏈接不僅僅是供人類或其選擇的 AI 閱讀的文檔。這些規范在設計上是機器可讀的，但只有在工具支持的情況下才真正有效。工具制造商及其社區可以通過實現對 API 請求的支持來使這些鏈接 API 請求的標準取得成功。
文章來源：How to Link API Requests Effectively
