创建可从 Azure 逻辑应用调用的自定义 APICreate custom APIs you can call from Azure Logic Apps

虽然 Azure 逻辑应用提供可用于逻辑应用工作流的数百个内置连接器,但建议调用不作为连接器提供的 API、系统和服务。Although Azure Logic Apps offers hundreds of connectors that you can use in logic app workflows, you might want to call APIs, systems, and services that aren't available as connectors. 可以创建自己的 API,提供在逻辑应用中使用的操作和触发器。You can create your own APIs that provide actions and triggers to use in logic apps. 下面是一些其他理由,解释为何建议创建可从逻辑应用工作流调用的自定义 API:Here are other reasons why you might want to create your own APIs that you can call from logic app workflows:

  • 扩展当前系统集成和数据集成工作流。Extend your current system integration and data integration workflows.
  • 帮助客户使用服务来管理专业或个人任务。Help customers use your service to manage professional or personal tasks.
  • 扩展服务的市场宣传、可发现性和使用。Expand the reach, discoverability, and use for your service.

连接器本质上是 Web API,此类 API 将 REST 用于可插入接口、将 Swagger 元数据格式用于文档、将 JSON 用作其数据交换格式。Basically, connectors are web APIs that use REST for pluggable interfaces, Swagger metadata format for documentation, and JSON as their data exchange format. 因为连接器是通过 HTTP 终结点进行通信的 REST API,所以可以使用任何语言生成连接器,如 .NET、Java、Python 或 Node.js。Because connectors are REST APIs that communicate through HTTP endpoints, you can use any language, like .NET, Java, Python, or Node.js, for building connectors. 此外,还可在 Azure 应用服务上托管API,前者是一款平台即服务 (PaaS) 产品,可为 API 托管提供一种最简单且可缩放性最高的最佳方法。You can also host your APIs on Azure App Service, a platform-as-a-service (PaaS) offering that provides one of the best, easiest, and most scalable ways for API hosting.

对于要用于逻辑应用的自定义 API,API 可以提供在逻辑应用工作流中执行特定任务的操作For custom APIs to work with logic apps, your API can provide actions that perform specific tasks in logic app workflows. API 还可充当触发器,在新数据或事件满足指定条件时启动逻辑应用工作流。Your API can also act as a trigger that starts a logic app workflow when new data or an event meets a specified condition. 本主题介绍根据想要 API 提供的行为,在 API 中生成操作和触发器可以遵循的常见模式。This topic describes common patterns that you can follow for building actions and triggers in your API, based on the behavior that you want your API to provide.

可在 Azure App Service 上托管API,它是一款平台即服务 (PaaS) 产品,可提供简单的高缩放性 API 托管。You can host your APIs on Azure App Service, a platform-as-a-service (PaaS) offering that provides highly scalable, easy API hosting.

Tip

虽然可以将 API 部署为 Web 应用,但请考虑将 API 部署为 API 应用,这样可以更轻松地在云和本地生成、托管和使用 API。Although you can deploy your APIs as web apps, consider deploying your APIs as API apps, which can make your job easier when you build, host, and consume APIs in the cloud and on premises. 不必更改 API 中的任何代码 - 可直接将代码部署到 API 应用。You don't have to change any code in your APIs -- just deploy your code to an API app. 例如,了解如何生成使用以下语言创建的 API 应用:For example, learn how to build API apps created with these languages:

有关为逻辑应用生成的 API 应用示例,请访问 Azure 逻辑应用 GitHub 存储库博客For API App samples built for logic apps, visit the Azure Logic Apps GitHub repository or blog.

自定义 API 和自定义连接器有何不同?How do custom APIs differ from custom connectors?

本质上来说,自定义 API 和自定义连接器都是 Web API,此类 API 将 REST 用于可插入接口、将 Swagger 元数据格式用于文档、将 JSON 用作其数据交换格式。Custom APIs and custom connectors are web APIs that use REST for pluggable interfaces, Swagger metadata format for documentation, and JSON as their data exchange format. 因为这些 API 和连接器是通过 HTTP 终结点进行通信的 REST API,所以可以使用任何语言生成自定义 API 和连接器,如 .NET、Java、Python 或 Node.js。And because these APIs and connectors are REST APIs that communicate through HTTP endpoints, you can use any language, like .NET, Java, Python, or Node.js, for building custom APIs and connectors.

自定义 API 允许调用非连接器 API,并提供可使用 HTTP + Swagger、Azure API 管理或应用程序服务调用的终结点。Custom APIs let you call APIs that aren't connectors, and provide endpoints that you can call with HTTP + Swagger, Azure API Management, or App Services. 自定义连接器的工作方式与自定义 API 类似,但它还具有以下属性:Custom connectors work like custom APIs but also have these attributes:

  • 在 Azure 中注册为逻辑应用连接器资源。Registered as Logic Apps Connector resources in Azure.
  • 在逻辑应用设计器中,显示在 Microsoft 托管连接器旁边(含图标)。Appear with icons alongside Microsoft-managed connectors in the Logic Apps Designer.
  • 仅适用于满足以下条件的连接器创建者和逻辑应用用户:在部署逻辑应用的区域中具有相同的 Azure Active Directory 租户和 Azure 订阅。Available only to the connectors' authors and logic app users who have the same Azure Active Directory tenant and Azure subscription in the region where the logic apps are deployed.

还可指定注册的连接器进行 Microsoft 认证。You can also nominate registered connectors for Microsoft certification. 此过程验证注册的连接器是否满足公共使用的条件,并使这些连接器可供 Power Automate 和 Microsoft Power Apps 中的用户使用。This process verifies that registered connectors meet the criteria for public use and makes those connectors available for users in Power Automate and Microsoft Power Apps.

有关自定义连接器的详细信息,请参阅For more information about custom connectors, see

有用的工具Helpful tools

当 API 也具有描述 API 操作和参数的 Swagger 文档时,自定义 API 最适用于逻辑应用。A custom API works best with logic apps when the API also has a Swagger document that describes the API's operations and parameters. 许多库(如 Swashbuckle)可自动为你生成 Swagger 文件。Many libraries, like Swashbuckle, can automatically generate the Swagger file for you. 若要批注 Swagger 文件的显示名称、属性类型等,也可使用 TRex 以便 Swagger 文件更适用于逻辑应用。To annotate the Swagger file for display names, property types, and so on, you can also use TRex so that your Swagger file works well with logic apps.

操作模式Action patterns

对于执行任务的逻辑应用,自定义 API 应提供操作For logic apps to perform tasks, your custom API should provide actions. API 中的每个操作 (operation) 将映射到操作 (action)。Each operation in your API maps to an action. 基本操作是接受 HTTP 请求并返回 HTTP 响应的控制器。A basic action is a controller that accepts HTTP requests and returns HTTP responses. 例如,逻辑应用将 HTTP 请求发送到 Web 应用或 API 应用。So for example, a logic app sends an HTTP request to your web app or API app. 然后应用返回 HTTP 响应及逻辑应用可处理的内容。Your app then returns an HTTP response, along with content that the logic app can process.

对于标准操作,可在 API 中编写 HTTP 请求方法,并在 Swagger 文件中描述该方法。For a standard action, you can write an HTTP request method in your API and describe that method in a Swagger file. 然后,可以使用 HTTP 操作HTTP + Swagger 操作直接调用 API。You can then call your API directly with an HTTP action or an HTTP + Swagger action. 默认情况下,必须在请求超时限制内返回响应。By default, responses must be returned within the request timeout limit.

标准操作模式

要在 API 完成较长时间运行的任务时使逻辑应用等待,API 可以遵循本主题中所述的异步轮询模式异步 Webhook 模式To make a logic app wait while your API finishes longer-running tasks, your API can follow the asynchronous polling pattern or the asynchronous webhook pattern described in this topic. 为帮助你形象化这些模式的不同行为,把这一过程想象成从面包店预定定制的蛋糕。For an analogy that helps you visualize these patterns' different behaviors, imagine the process for ordering a custom cake from a bakery. 轮询模式类似于你每隔 20 分钟打电话给面包店询问蛋糕是否做好。The polling pattern mirrors the behavior where you call the bakery every 20 minutes to check whether the cake is ready. Webhook 模式类似于面包店记下你的电话号码以便蛋糕做好后打电话给你。The webhook pattern mirrors the behavior where the bakery asks you for your phone number so they can call you when the cake is ready.

有关示例,请访问逻辑应用 GitHub 存储库For samples, visit the Logic Apps GitHub repository. 此外,详细了解操作的用量计量Also, learn more about usage metering for actions.

使用轮询操作模式执行长时间运行任务Perform long-running tasks with the polling action pattern

为使 API 执行时间超过请求超时限制的任务,可以使用异步轮询模式。To have your API perform tasks that could run longer than the request timeout limit, you can use the asynchronous polling pattern. 此模式使 API 在单独线程中执行任务,但与逻辑应用引擎保持活动连接。This pattern has your API do work in a separate thread, but keep an active connection to the Logic Apps engine. 这样一来,在 API 完成工作之前,逻辑应用不会超时或继续进行工作流的下一步。That way, the logic app does not time out or continue with the next step in the workflow before your API finishes working.

以下是常规模式:Here's the general pattern:

  1. 请确保引擎知道 API 接受了请求并已开始工作。Make sure that the engine knows that your API accepted the request and started working.
  2. 当引擎针对作业状态进行后续请求时,让引擎知道 API 完成任务的时间。When the engine makes subsequent requests for job status, let the engine know when your API finishes the task.
  3. 返回引擎的相关数据,以便逻辑应用工作流可以继续。Return relevant data to the engine so that the logic app workflow can continue.

现在将之前的面包店类比用于轮询模式,假设你打电话给面包店预订定制的蛋糕并要求送货。Now apply the previous bakery analogy to the polling pattern, and imagine that you call a bakery and order a custom cake for delivery. 做蛋糕的过程需要花费时间,而且你不想在面包店做蛋糕的时候拿着电话等待。The process for making the cake takes time, and you don't want to wait on the phone while the bakery works on the cake. 面包店确认订单,并让你每隔 20 分钟打电话确认蛋糕是否做好。The bakery confirms your order and has you call every 20 minutes for the cake's status. 20 分钟之后,你打电话给面包店,但是面包店告诉你蛋糕还没有做好,请过 20 分钟再打电话。After 20 minutes pass, you call the bakery, but they tell you that your cake isn't done and that you should call in another 20 minutes. 这一来一回的过程持续到面包店告诉你面包已经做好并且送出。This back-and-forth process continues until you call, and the bakery tells you that your order is ready and delivers your cake.

那么让我们回来轮询模式。So let's map this polling pattern back. 面包店代表自定义 API,而你 - 预订蛋糕的客户代表逻辑应用引擎。The bakery represents your custom API, while you, the cake customer, represent the Logic Apps engine. 当引擎通过请求调用 API 时, API 确认请求,并隔段时间在引擎检查作业状态时进行响应。When the engine calls your API with a request, your API confirms the request and responds with the time interval when the engine can check job status. 引擎继续检查作业状态,直到 API 响应作业已完成,并将数据返回给逻辑应用,随之推进工作流。The engine continues checking job status until your API responds that the job is done and returns data to your logic app, which then continues workflow.

轮询操作模式

以下是 API 要跟随的具体步骤(从 API 的角度):Here are the specific steps for your API to follow, described from the API's perspective:

  1. 当 API 获取 HTTP 请求开始工作时,立即返回 HTTP 202 ACCEPTED 响应与此步骤中后面所述的 location 标头。When your API gets an HTTP request to start work, immediately return an HTTP 202 ACCEPTED response with the location header described later in this step. 此响应让逻辑应用引擎知道 API 收到了请求、接受了请求有效负载(数据输入),并且现在正在处理。This response lets the Logic Apps engine know that your API got the request, accepted the request payload (data input), and is now processing.

    202 ACCEPTED 响应应包含这些标头:The 202 ACCEPTED response should include these headers:

    • 必需 :用于指定逻辑应用引擎检查 API 作业状态的 URL 的绝对路径的 location 标头Required: A location header that specifies the absolute path to a URL where the Logic Apps engine can check your API's job status

    • 可选:用于指定引擎检查 location URL 获知作业状态之前应等待秒数的 retry-after 标头。Optional: A retry-after header that specifies the number of seconds that the engine should wait before checking the location URL for job status.

      默认情况下,引擎每隔 20 秒检查一次。By default, the engine checks every 20 seconds. 若要指定不同的时间间隔,请包括 retry-after 标头和下次轮询前的秒数。To specify a different interval, include the retry-after header and the number of seconds until the next poll.

  2. 超过指定的时间后,逻辑应用引擎轮询 location URL 来检查作业状态。After the specified time passes, the Logic Apps engine polls the location URL to check job status. API 应执行以下检查,并返回以下响应:Your API should perform these checks and return these responses:

    • 如果作业已完成,返回 HTTP 200 OK 响应及响应有效负载(下一步的输入)。If the job is done, return an HTTP 200 OK response, along with the response payload (input for the next step).

    • 如果作业仍在处理,返回另一个 HTTP 202 ACCEPTED 响应,但其标头与初始响应相同。If the job is still processing, return another HTTP 202 ACCEPTED response, but with the same headers as the original response.

当 API 遵循此模式时,若要继续检查作业状态,无需在逻辑应用工作流定义中执行任何操作。When your API follows this pattern, you don't have to do anything in the logic app workflow definition to continue checking job status. 当引擎获取 HTTP 202 ACCEPTED 响应和有效的 location 标头,引擎尊重异步模式,并检查 location 标头,直到 API 返回非 202 响应。When the engine gets an HTTP 202 ACCEPTED response and a valid location header, the engine respects the asynchronous pattern and checks the location header until your API returns a non-202 response.

Tip

有关异步模式的示例,查看 GitHub 中异步控制器响应示例For an example asynchronous pattern, review this asynchronous controller response sample in GitHub.

使用 Webhook 操作模式执行长时间运行任务Perform long-running tasks with the webhook action pattern

作为替代方法,可对长时间运行的任务和异步处理使用 Webhook 模式。As an alternative, you can use the webhook pattern for long-running tasks and asynchronous processing. 此模式让逻辑应用暂停并等待 API 的“回叫”,以完成处理并继续工作流。This pattern has the logic app pause and wait for a "callback" from your API to finish processing before continuing workflow. 此回叫是在事件发生时将消息发送到 URL 的 HTTP POST。This callback is an HTTP POST that sends a message to a URL when an event happens.

现在将之前的面包店类比用于 Webhook 模式,假设你打电话给面包店预订定制的蛋糕并要求送货。Now apply the previous bakery analogy to the webhook pattern, and imagine that you call a bakery and order a custom cake for delivery. 做蛋糕的过程需要花费时间,而且你不想在面包店做蛋糕的时候拿着电话等待。The process for making the cake takes time, and you don't want to wait on the phone while the bakery works on the cake. 面包店确认你的订单,但这一次,你把电话号码给面包店,以便蛋糕做好后他们可以给你打电话。The bakery confirms your order, but this time, you give them your phone number so they can call you when the cake is done. 这次面包店在蛋糕做好并送出时告知你。This time, the bakery tells you when your order is ready and delivers your cake.

我们回到 Webhook 模式,面包店代表自定义 API,而你 - 预订蛋糕的客户代表逻辑应用引擎。When we map this webhook pattern back, the bakery represents your custom API, while you, the cake customer, represent the Logic Apps engine. 引擎通过请求调用 API,且包括了“回叫”URL。The engine calls your API with a request and includes a "callback" URL. 完成作业后,API 使用 URL 来通知引擎并将数据返回到逻辑应用,然后继续工作流。When the job is done, your API uses the URL to notify the engine and return data to your logic app, which then continues workflow.

对于此模式,在控制器上设置两个终结点:subscribeunsubscribeFor this pattern, set up two endpoints on your controller: subscribe and unsubscribe

  • subscribe 终结点:当执行到达工作流中的 API 操作时,逻辑应用引擎调用 subscribe 终结点。subscribe endpoint: When execution reaches your API's action in the workflow, the Logic Apps engine calls the subscribe endpoint. 此步骤导致逻辑应用创建 API 将存储的回叫 URL,然后等待工作完成时 API 的回叫。This step causes the logic app to create a callback URL that your API stores and then wait for the callback from your API when work is complete. API 通过 HTTP POST 回叫 URL,并将任何返回的内容和标头作为输入传递到逻辑应用。Your API then calls back with an HTTP POST to the URL and passes any returned content and headers as input to the logic app.

  • unsubscribe 终结点: 如果逻辑应用运行已取消,逻辑应用引擎将调用 unsubscribe 终结点。unsubscribe endpoint: If the logic app run is canceled, the Logic Apps engine calls the unsubscribe endpoint. 然后 API 可以取消注册回叫 URL,并根据需要停止任何进程。Your API can then unregister the callback URL and stop any processes as necessary.

Webhook 操作模式

Note

目前,逻辑应用设计器不支持通过 Swagger 发现 Webhook 终结点。Currently, the Logic App Designer doesn't support discovering webhook endpoints through Swagger. 因此对于此模式,需要添加 Webhook 操作并指定 URL、标头以及请求正文。So for this pattern, you have to add a Webhook action and specify the URL, headers, and body for your request. 另请参阅工作流操作和触发器See also Workflow actions and triggers. 若要传入回叫 URL,可以根据需要使用以前任何字段中的 @listCallbackUrl() 工作流函数。To pass in the callback URL, you can use the @listCallbackUrl() workflow function in any of the previous fields as necessary.

Tip

有关 Webhook 模式的示例,查看 GitHub 中的 Webhook 触发器示例For an example webhook pattern, review this webhook trigger sample in GitHub.

触发器模式Trigger patterns

自定义 API 还可充当触发器,在新数据或事件满足指定条件时启动逻辑应用。Your custom API can act as a trigger that starts a logic app when new data or an event meets a specified condition. 此触发器可以定期检查或者等待侦听服务终结点上的新数据或事件。This trigger can either check regularly, or wait and listen, for new data or events at your service endpoint. 如果新数据或事件满足指定的条件,触发器触发并启动正在侦听该触发器的逻辑应用。If new data or an event meets the specified condition, the trigger fires and starts the logic app, which is listening to that trigger. 若要以这种方式启动逻辑应用,API 可以遵循轮询触发器Webhook 触发器模式。To start logic apps this way, your API can follow the polling trigger or the webhook trigger pattern. 这些模式类似于其轮询操作Webhook 操作的对应项。These patterns are similar to their counterparts for polling actions and webhook actions. 另请详细了解触发器的用量计量Also, learn more about usage metering for triggers.

使用轮询触发器模式定期检查新数据或事件Check for new data or events regularly with the polling trigger pattern

轮询触发器 的行为非常类似于本主题中前面所述的轮询操作A polling trigger acts much like the polling action previously described in this topic. 逻辑应用引擎定期调用并检查触发器终结点,查看新数据或事件。The Logic Apps engine periodically calls and checks the trigger endpoint for new data or events. 如果引擎发现满足指定条件的新数据或事件,触发器即触发。If the engine finds new data or an event that meets your specified condition, the trigger fires. 然后,引擎创建将数据处理为输入的逻辑应用实例。Then, the engine creates a logic app instance that processes the data as input.

轮询触发器模式

Note

每个轮询请求算作操作执行,即使未创建任何逻辑应用实例。Each polling request counts as an action execution, even when no logic app instance is created. 若要防止多次处理相同数据,触发器应清理已读取且传递到逻辑应用的数据。To prevent processing the same data multiple times, your trigger should clean up data that was already read and passed to the logic app.

以下是轮询触发器的具体步骤(从 API 的角度):Here are specific steps for a polling trigger, described from the API's perspective:

找到新数据或事件?Found new data or event? API 响应API response
已找到Found 返回 HTTP 200 OK 状态与响应有效负载(下一步的输入)。Return an HTTP 200 OK status with the response payload (input for next step).
此响应创建逻辑应用实例,并启动工作流。This response creates a logic app instance and starts the workflow.
未找到Not found 返回 HTTP 202 ACCEPTED 状态与 location 标头和 retry-after 标头。Return an HTTP 202 ACCEPTED status with a location header and a retry-after header.
对于触发器,location 标头还应包含 triggerState 查询参数,通常是“时间戳”。For triggers, the location header should also contain a triggerState query parameter, which is usually a "timestamp." API 可以使用此标识符跟踪上次触发逻辑应用的时间。Your API can use this identifier to track the last time that the logic app was triggered.

例如,若要定期检查服务的新文件,可生成具有以下行为的轮询触发器:For example, to periodically check your service for new files, you might build a polling trigger that has these behaviors:

请求是否包含 triggerStateRequest includes triggerState? API 响应API response
No 返回 HTTP 202 ACCEPTED 状态及 triggerState 设置为当前时间、retry-after 间隔为 15 秒的 location 标头。Return an HTTP 202 ACCEPTED status plus a location header with triggerState set to the current time and the retry-after interval to 15 seconds.
Yes triggerStateDateTime 之后检查服务的已添加文件。Check your service for files added after the DateTime for triggerState.
找到的文件数Number of files found API 响应API response
单个文件Single file 返回 HTTP 200 OK 状态和内容有效负载,将返回文件的 triggerState 更新为 DateTime,并将 retry-after 间隔设置为 15 秒。Return an HTTP 200 OK status and the content payload, update triggerState to the DateTime for the returned file, and set retry-after interval to 15 seconds.
多个文件Multiple files 每次返回一个文件和 HTTP 200 OK 状态,更新 triggerState,并将 retry-after 间隔设置为 0 秒。Return one file at a time and an HTTP 200 OK status, update triggerState, and set the retry-after interval to 0 seconds.
这些步骤让引擎知道更多数据已可用,而且引擎应立即通过 location 标头中的 URL 请求数据。These steps let the engine know that more data is available, and that the engine should immediately request the data from the URL in the location header.
无文件No files 返回 HTTP 202 ACCEPTED 状态,不更改 triggerState,并将 retry-after 间隔设置为 15 秒。Return an HTTP 202 ACCEPTED status, don't change triggerState, and set the retry-after interval to 15 seconds.

Tip

有关轮询触发器模式的示例,请查看 GitHub 中的轮询触发器控制器示例For an example polling trigger pattern, review this poll trigger controller sample in GitHub.

使用 Webhook 触发器模式等待和侦听新数据或事件Wait and listen for new data or events with the webhook trigger pattern

Webhook 触发器是推送触发器 ,等待并侦听服务终结点上的新数据或事件。A webhook trigger is a push trigger that waits and listens for new data or events at your service endpoint. 如果新数据或事件满足指定的条件,触发器即触发,并创建逻辑应用实例,然后将数据处理为输入。If new data or an event meets the specified condition, the trigger fires and creates a logic app instance, which then processes the data as input. Webhook 触发器的行为非常类似于之前本主题中所述的 Webhook 操作,并设置有 subscribeunsubscribe 终结点。Webhook triggers act much like the webhook actions previously described in this topic, and are set up with subscribe and unsubscribe endpoints.

  • subscribe 终结点:在逻辑应用中添加和保存 Webhook 触发器时,逻辑应用引擎调用 subscribe 终结点。subscribe endpoint: When you add and save a webhook trigger in your logic app, the Logic Apps engine calls the subscribe endpoint. 此步骤将导致逻辑应用创建 API 将存储的回叫 URL。This step causes the logic app to create a callback URL that your API stores. 存在满足指定条件的新数据或事件时, API 通过 HTTP POST 回叫 URL。When there's new data or an event that meets the specified condition, your API calls back with an HTTP POST to the URL. 内容有效负载和标头作为输入传递到逻辑应用。The content payload and headers pass as input to the logic app.

  • unsubscribe 终结点:如果删除 Webhook 触发器或整个逻辑应用,逻辑应用引擎调用 unsubscribe 终结点。unsubscribe endpoint: If the webhook trigger or entire logic app is deleted, the Logic Apps engine calls the unsubscribe endpoint. 然后 API 可以取消注册回叫 URL,并根据需要停止任何进程。Your API can then unregister the callback URL and stop any processes as necessary.

Webhook 触发器模式

Note

目前,逻辑应用设计器不支持通过 Swagger 发现 Webhook 终结点。Currently, the Logic App Designer doesn't support discovering webhook endpoints through Swagger. 因此对于此模式,需要添加 Webhook 触发器并指定 URL、 标头以及请求正文。So for this pattern, you have to add a Webhook trigger and specify the URL, headers, and body for your request. 另请参阅 HTTPWebhook 触发器See also HTTPWebhook trigger. 若要传入回叫 URL,可以根据需要使用以前任何字段中的 @listCallbackUrl() 工作流函数。To pass in the callback URL, you can use the @listCallbackUrl() workflow function in any of the previous fields as necessary.

若要防止多次处理相同数据,触发器应清理已读取且传递到逻辑应用的数据。To prevent processing the same data multiple times, your trigger should clean up data that was already read and passed to the logic app.

Tip

有关 Webhook 模式的示例,请查看 GitHub 中的 Webhook 触发器控制器示例For an example webhook pattern, review this webhook trigger controller sample in GitHub.

通过逻辑应用保护对 API 的调用Secure calls to your APIs from logic apps

创建自定义 API 后,请为 API 设置身份验证,以便可以通过逻辑应用安全地调用它们。After creating your custom APIs, set up authentication for your APIs so that you can call them securely from logic apps. 了解如何通过逻辑应用保护对自定义 API 的调用Learn how to secure calls to custom APIs from logic apps.

部署和调用 APIDeploy and call your APIs

设置身份验证后,请为 API 设置部署。After you set up authentication, set up deployment for your APIs. 了解如何通过逻辑应用部署和调用自定义 APILearn how to deploy and call custom APIs from logic apps.

将自定义 API 发布到 AzurePublish custom APIs to Azure

要使自定义 API 可供 Azure 中其他逻辑应用用户使用,必须添加安全性并将这些 API 注册为逻辑应用连接器。To make your custom APIs available for other Logic Apps users in Azure, you must add security and register them as Logic App connectors. 有关详细信息,请参阅自定义连接器概述For more information, see Custom connectors overview.

要使自定义 API 可供逻辑应用、Power Automate 和 Microsoft Power Apps 中所有用户使用,必须添加安全性、将 API 注册为逻辑应用连接器并向 Microsoft Azure 认证计划提名你的连接器。To make your custom APIs available to all users in Logic Apps, Power Automate, and Microsoft Power Apps, you must add security, register your APIs as Logic App connectors, and nominate your connectors for the Microsoft Azure Certified program.

获取支持Get support

后续步骤Next steps