A storefront calling a catalog API needs an address, but that address or port may change as independently running services move. Service discovery lets the storefront use the API’s registered name instead of hardcoding its network location. In Aspire, the AppHost declares the services and their relationships; service defaults equip the applications to resolve those names. section 1.0 section 1.9.3
More generally, discovery involves registering a service’s location, querying for it, and updating that information as services join or leave. Load balancing is closely related but is not itself service discovery. section 1.9
To use named HTTP endpoints in an Aspire application:
- Declare the API as a named project in AppHost and give the storefront a reference to it. section 10.2 section 1.10
- Add Microsoft.Extensions.ServiceDiscovery to the service-defaults project. In AddServiceDefaults(), call builder.Services.AddServiceDiscovery() and configure HTTP clients with http.AddServiceDiscovery(). section 1.9.1 section 1.9.2
- Call AddServiceDefaults() in the application, then set the HTTP client’s base address to the API’s registered name rather than an IP address. section 1.9.3
client.BaseAddress = new("https+http://apiservice");
The storefront client uses the registered name apiservice. The https+http scheme prefers HTTPS and falls back to HTTP; the client does not need the API’s current address or port. section 1.9.3
Not every integration accepts a discovery-aware HTTP client automatically. For a SignalR connection, pass an IHttpMessageHandlerFactory into the connection builder and assign its handler to the connection options; a URL naming the Aspire-hosted API can then be resolved. An Ollama integration offers another boundary: a discovery-enabled HTTP client can resolve its container name, but the Semantic Kernel connector shown here requires an endpoint extracted from an Aspire-supplied connection string. section 4.4.2 section 5.2.1
Browser-facing SSO redirects need standard, publicly accessible URLs, not an https+http service name understood only by the discovery library. For local development, AppHost can obtain the storefront’s HTTP or HTTPS endpoint and pass its URL to the identity provider through environment variables. That endpoint-reading code is restricted to development because hosted service addresses may not yet be available at the same point on a real host. section 8.2
