A REST API with Swagger becomes even more valuable when the consumer is a Blazor Server front end, because server-side Blazor has the same access to HTTP services as any backend component. In a Blazor Server enterprise app the browser talks to the server over a SignalR circuit, while the server talks to the REST API over plain HTTP. That separation means your API stays versioned, documented, and testable — and the front end simply consumes the contract that Swagger UI describes.
This article shows the pieces Indotalent uses in every product: a typed HttpClient that mirrors the API, JWT auth for every call, and Swagger UI as the reference manual for front-end developers. When the API changes, the Swagger document changes first, and the Blazor front end updates against the new contract.
REST API with Swagger: The Contract for Blazor
Swagger UI is not just for backend engineers. In a Blazor Server shop, it is the contract that front-end developers code against. Before writing any UI, a developer opens the Swagger UI, reads the request and response schemas, and knows exactly which DTOs the page needs. That shared vocabulary is what lets the front end and the API evolve without constant meetings.
The same OpenAPI document can drive client generation. Tools read the JSON served at /swagger/v1/swagger.json and emit typed clients, so the C# classes in the Blazor project stay in sync with the API by construction.
REST API with Swagger: A Typed HttpClient in Blazor Server
Register a typed client in Program.cs, configure the base address and the default authorization header, and inject it into any component. The DI container handles lifetime and disposal.
builder.Services.AddHttpClient<ICustomerClient, CustomerClient>(client =>
{
client.BaseAddress = new Uri("https://api.indotalent.com");
client.DefaultRequestHeaders.Authorization =
new AuthenticationHeaderValue("Bearer", AccessToken);
});The client interface mirrors the API surface exactly — one method per endpoint. The implementation delegates to HttpClient and deserializes the JSON into DTOs that match the OpenAPI schemas from the Swagger document.
public interface ICustomerClient
{
Task<CustomerDto> GetCustomerAsync(Guid id, CancellationToken ct = default);
}
public class CustomerClient : ICustomerClient
{
private readonly HttpClient _http;
public CustomerClient(HttpClient http) => _http = http;
public async Task<CustomerDto> GetCustomerAsync(Guid id, CancellationToken ct)
{
var customer = await _http.GetFromJsonAsync<CustomerDto>(
$"/api/v1/customers/{id}", ct)
?? throw new InvalidOperationException("Customer not found.");
return customer;
}
}In a page, inject the client and call it inside OnInitializedAsync or a button handler. Blazor Server's SignalR circuit keeps the UI responsive while the HTTP call completes in the background. The same technique works for every service in the platform: catalog, orders, invoices, and identity each get their own client, and each client is a small file the team can review in seconds.
REST API with Swagger: Why Server-Side Blazor Fits
Some teams assume Blazor Server and a REST API are redundant — after all, both run on the server. They are not. The Blazor app renders the UI and owns the SignalR circuit; the REST API owns the data and the business rules. The UI can be replaced without touching the API, and the API can be shared with a mobile client, a partner, or another web app. The REST API with Swagger is the stable layer; Blazor Server is one of its consumers.
In practice the circuit and the API often share the same host, but they must not share state. The DbContext belongs to the API project, while the Blazor app owns the circuit, the authentication cookies, and the UI state. Keeping that boundary explicit means you can scale the API independently, swap the UI for a native client, or move the API to a different host without rebuilding the front end. The Swagger document is the memory that holds the boundary together — every contract decision is written down where both sides can see it.
REST API with Swagger: Enterprise Patterns Worth Copying
Indotalent products pair the typed-client pattern with a few extras that matter in production. Each product registers the client with a base address from configuration, refreshes the JWT through the token endpoint, and adds resilience policies for transient failures.
- Register one typed client per API module — CustomerClient, OrderClient, and so on
- Read the base address and token endpoint from configuration, never from constants
- Attach the bearer token through a custom handler so it can refresh automatically
- Generate DTOs from the OpenAPI document to keep schemas in sync
- Test the API against Swagger UI before wiring any Blazor page
Key Takeaways
- Blazor Server consumes a REST API over plain HTTP while the browser talks over SignalR
- Swagger UI is the contract that Blazor front-end developers code against
- Typed HttpClient clients mirror the API and keep components free of HTTP plumbing
- Server-side Blazor and a documented REST API are complementary, not redundant
- Every Indotalent product ships this pairing — $21 each
FAQ
Can Blazor Server call an API directly from a component?
Yes. Inject an HttpClient or a typed client into the component and call it in lifecycle methods or event handlers.
Does Blazor Server need to use its own REST API?
No, but it should. A separate REST API with Swagger keeps the data layer shareable, testable, and versionable independently of the UI.
How do I keep the Blazor DTOs in sync with the API?
Generate them from the OpenAPI document, or copy the response schemas from Swagger UI when the API changes.
Where does the JWT token come from in Blazor Server?
A login endpoint issues it; the typed client stores it and attaches it as the Authorization header for subsequent calls.