The documentation you are viewing is for Dapr v1.11 which is an older version of Dapr. For up-to-date documentation, see the latest version.

How-To: Invoke Non-Dapr Endpoints using HTTP

Call Non-Dapr endpoints from Dapr applications using service invocation

This article demonstrates how to call a non-Dapr endpoint using Dapr over HTTP.

Using Dapr’s service invocation API, you can communicate with endpoints that either use or do not use Dapr. Using Dapr to call endpoints that do not use Dapr not only provides a consistent API, but also the following Dapr service invocation benefits:

  • Ability to apply resiliency policies
  • Call observability with tracing & metrics
  • Security access control through scoping
  • Ability to utilize middleware pipeline components
  • Service discovery
  • Authentication through the use of headers

HTTP service invocation to external services or non-Dapr endpoints

Sometimes you need to call a non-Dapr HTTP endpoint. For example:

  • You may choose to only use Dapr in part of your overall application, including brownfield development
  • You may not have access to the code to migrate an existing application to use Dapr
  • You need to call an external HTTP service.

By defining an HTTPEndpoint resource, you declaratively define a way to interact with a non-Dapr endpoint. You then use the service invocation URL to invoke non-Dapr endpoints. Alternatively, you can place a non-Dapr Fully Qualified Domain Name (FQDN) endpoint URL directly into the service invocation URL.

Order of precedence between HttpEndpoint, FQDN URL, and appId

When using service invocation, the Dapr runtime follows a precedence order:

  1. Is this a named HTTPEndpoint resource?
  2. Is this an FQDN URL with anhttp:// or https:// prefix?
  3. Is this an appID?

Service invocation and non-Dapr HTTP endpoint

The diagram below is an overview of how Dapr’s service invocation works when invoking non-Dapr endpoints.

Diagram showing the steps of service invocation to non-Dapr endpoints
  1. Service A makes an HTTP call targeting Service B, a non-Dapr endpoint. The call goes to the local Dapr sidecar.
  2. Dapr discovers Service B’s location using the HTTPEndpoint or FQDN URL.
  3. Dapr forwards the message to Service B.
  4. Service B runs its business logic code.
  5. Service B sends a response to Service A’s Dapr sidecar.
  6. Service A receives the response.

Using an HTTPEndpoint resource or FQDN URL for non-Dapr endpoints

There are two ways to invoke a non-Dapr endpoint when communicating either to Dapr applications or non-Dapr applications. A Dapr application can invoke a non-Dapr endpoint by providing one of the following:

  • A named HTTPEndpoint resource, including defining an HTTPEndpoint resource type. See the HTTPEndpoint reference guide for an example.

    localhost:3500/v1.0/invoke/<HTTPEndpoint-name>/method/<my-method>
    

    For example, with an HTTPEndpoint resource called “palpatine” and a method called “Order66”, this would be:

    curl http://localhost:3500/v1.0/invoke/palpatine/method/order66
    
  • A FQDN URL to the non-Dapr endpoint.

    localhost:3500/v1.0/invoke/<URL>/method/<my-method>
    

    For example, with an FQDN resource called https://darthsidious.starwars, this would be:

    curl http://localhost:3500/v1.0/invoke/https://darthsidious.starwars/method/order66
    

Using appId when calling Dapr enabled applications

AppIDs are always used to call Dapr applications with the appID and `my-method``. Read the How-To: Invoke services using HTTP guide for more information. For example:

localhost:3500/v1.0/invoke/<appID>/method/<my-method>
curl http://localhost:3602/v1.0/invoke/orderprocessor/method/checkout

Community call demo

Watch this video on how to use service invocation to call non-Dapr endpoints.


Last modified September 6, 2023: update per mark (ad6cfeb8)