API tierces dans Blazor WebAssembly

Découvrez comment intégrer les API tierces dans les applications Blazor WebAssembly, traitant des problèmes COR et de la gestion des erreurs.

Blazor WebAssembly a été impliqué dans un cadre Web de première classe pour créer des applications Web interactives à l’aide de C # et .NET.

En plus d’offrir des API simples et puissantes pour le rendu de l’interface utilisateur, Blazor s’intègre également aux API internes et externes. Dans cet article, nous explorerons comment consommer des API de Blazor WebAssembly et comment faire face à des problèmes communs, tels que CORS et la gestion des erreurs.

Tu peux accéder au code utilisé dans cet exemple sur github.

Appel API à l’aide du type httpclient

Le HttpClient Le type donne accès aux API. Tout d’abord, nous devons enregistrer le HttpClient avec Client projet (webassembly) et (en raison de la prétention) avec le Server Projet (ASP.NET Core).

Projet de serveur:

builder.Services.AddHttpClient();

Projet client:

builder.Services.AddScoped(sp =>
    new HttpClient
    {
        BaseAddress = new Uri(builder.HostEnvironment.BaseAddress)
    }
);

Dans le Client projet, nous utilisons le HostEnvironment propriété sur le builder objet pour accéder au BaseAddress de la Server projeter et le définir comme le BaseAddress de la HttpClient objet. Il nous permet de fournir des chemins relatifs dans le Client Projet lors de l’accès aux API à partir du Server projet.

Maintenant nous utilisons le @inject directive pour injecter une instance du HttpClient tapez dans le Weather composant de page dans le Client projet:

@inject HttpClient HttpClient

Dans la section Code, nous pouvons maintenant utiliser le HttpClient objet et c’est GetAsync Méthode pour charger les données de la /api/weather itinéraire.

Note: Si vous souhaitez apprendre à implémenter le contrôleur côté serveur qui fournit l’API, vous pouvez accéder au code utilisé dans cet exemple sur github.

@code {
    private WeatherForecast[]? forecasts;

    protected override async Task OnInitializedAsync()
    {
        var response = await HttpClient.GetAsync("/api/weather");
        var weatherForecasts = 
            await response.Content
                .ReadFromJsonAsync<IEnumerable<WeatherForecast>>();
        forecasts = weatherForecasts?.ToArray();
    }
}

Après avoir chargé les données en utilisant le GetAsync Méthode, nous utilisons le ReadFromJsonAsync Méthode et fournir un argument de type générique du type que nous attendons de l’API.

Enfin, nous attribuons la valeur renvoyée au privé forecasts champ pour rendre les données sur la page.

Utilisez la même API pour les API internes et externes

L’une des meilleures choses à utiliser HttpClient Pour accéder aux API, nous pouvons utiliser le même type et les mêmes méthodes pour charger les données des API internes (Project Server) et des API distantes (services étrangers).

Selon vos préférences, vous pouvez enregistrer un HttpClient Per API externe et injectez l’instance respective à vos composants Blazor.

Alternativement, vous pouvez utiliser la même instance pour tous les appels d’API et fournir un chemin relatif pour le chemin interne et un chemin absolu pour les API externes.

Utilisez un SDK dédié pour appeler des services externes

Certains services plus avancés, tels que Sentry, fournissent un SDK dédié pour le développement .NET.

L’avantage est que le SDK fournit une interface native, telle que les types et les méthodes qui représentent les opérations, au lieu d’avoir à implémenter les appels d’API en utilisant le HttpClient nous-mêmes.

L’intégration de ces API est plus simple que d’accès aux API en utilisant le HttpClient taper. Cependant, le HttpClient Le type fournit une interface générique qui vous permet d’accéder à n’importe quelle API HTTP, y compris celles sans SDK dédiée.

En fin de compte, la plupart des SDK dédiés utilisent le HttpClient Tapez leur implémentation et fournissez des méthodes de wrapper autour de lui.

Traiter les problèmes de COR

Lorsque vous passez des appels API à partir d’applications Web, nous frappons souvent Partage de ressources d’origine inter-originaux (CORS) problèmes.

Étant donné que Blazor WebAssembly s’exécute dans le navigateur, la stratégie de même d’origine du navigateur s’applique. Vous pouvez rencontrer des erreurs CORS si le serveur API n’autorise pas explicitement les demandes de l’origine de votre application.

Configuration des COR dans ASP.NET Core

La solution la plus simple pour résoudre les problèmes CORS consiste à configurer correctement le serveur. Dans le cas d’une application ASP.Net Core Server, nous utilisons le AddCors middleware et configurez-le en conséquence.

services.AddCors(options =>
{
    options.AddPolicy("BlazorClientApp",
        builder => builder.WithOrigins("https://blazor-wasm-app.com")
                          .AllowAnyMethod()
                          .AllowAnyHeader());
});

app.UseCors("AllowBlazorApp");

Nous ajoutons une stratégie nommée et avons permis à l’application client d’accéder au serveur. Nous avons un contrôle total sur les méthodes et les en-têtes HTTP que nous voulons permettre ou interdire.

Implémenter un proxy côté serveur

Si nous n’avons pas de contrôle sur le serveur, nous devons implémenter un proxy côté serveur.

Nous implémentons une API en wrapper (proxy de l’API) sur le serveur qui consomme l’API tiers et la fournit à l’application client. Étant donné que nous contrôlons l’application du serveur, nous pouvons configurer correctement l’application du serveur pour autoriser les connexions à partir de l’application client Blazor WebAssembly.

Il fonctionne parce que CORS est une technologie de navigateur côté client. Si nous nous connectons à l’API sur le serveur, CORS ne s’applique pas. Cependant, sachez que l’API doit toujours permettre l’accès. Par exemple, vous devez fournir un Clé API ou une autre forme d’authentification.

Gérer les données asynchrones récupérant avec une gestion des erreurs appropriée

La programmation asynchrone est la valeur par défaut du développement Web moderne, et Blazor WebAssembly n’est pas différent.

Il est essentiel d’exécuter et de gérer correctement les appels d’API pour une expérience utilisateur fluide.

Catch des exceptions lorsque vous utilisez le httpclient

Le point de départ le plus simple est d’ajouter try-catch déclarations HttpClient Les appels pour gérer gracieusement les erreurs telles que les défaillances du réseau ou les réponses HTTP non valides.

try
{
  var url = "https://api.example.com/data";
  data = await Http.GetFromJsonAsync<List<string>>(url);
}
catch (Exception ex)
{
  error = ex.Message;
}

Ce code vous permet de fournir un message d’erreur personnalisé à l’utilisateur et de enregistrer l’erreur dans vos journaux d’application.

Les erreurs de journalisation vous aident à trouver ces erreurs qui se produisent souvent. Sans erreurs de journalisation, vous pourriez même ne pas remarquer des erreurs qui se produisent dans votre application.

Améliorer l’expérience utilisateur avec le chargement des indicateurs d’état

Indicateurs de chargement vous permettez d’informer l’utilisateur que les données sont récupérées. Cela empêche l’application d’apparaître qui ne répond pas pendant les opérations plus longues, telles que les appels API.

Il existe plusieurs façons d’implémenter un indicateur de chargement lorsque vous travaillez avec Blazor. Je préfère l’approche suivante:

private async Task LoadCustomers()
{
  _isLoading = true;
  StateHasChanged();
  _customers = await CustomerService.GetAllCustomers();
  _isLoading = false;
  StateHasChanged();
}

Je définis un champ privé de type bool Pour maintenir les informations sur la question de savoir si les données se chargent. J’implémente également un async Load Méthode et définir le _isLoading se déplacer vers true. Ensuite, j’appelle le StateHasChanged Méthode pour s’assurer que l’indicateur de chargement s’affiche à l’écran.

Vous pouvez implémenter un indicateur de chargement personnalisé et le montrer en fonction de la valeur du _isLoading champ, ou vous pouvez utiliser l’un des composants existants, tels que le Chargeur de blazor de progrès Telerik UI pour Blazor.

Demandes de débouchement et de limitation

Certaines API limitent les demandes qu’un client peut envoyer dans un délai donné.

Exécution débouchant ou étranglement est une excellente stratégie pour minimiser le nombre de demandes envoyées dans un court laps de temps.

Certaines bibliothèques aiment Polly et Extensions réactives (RX.NET) vous aider dans une telle situation.

Conclusion

Les applications Web modernes consomment des API internes et externes. Le Web est connecté et nos applications ne fonctionnent pas dans un silo isolé.

Le HttpClient Le type fournit une interface asynchrone moderne, robuste et performante pour accéder aux API à l’aide du protocole HTTP.

Cors est un problème courant lorsque vous travaillez avec des API. Assurez-vous de définir les en-têtes CORS corrects en configurant votre service de backend ASP.NET. L’implémentation d’un proxy côté serveur peut être la seule option si vous consommez une API tierce.

Assurez-vous de gérer les erreurs à l’aide d’un try-catch déclaration lors de l’utilisation du HttpClient Tapez pour accéder aux API et à utiliser indicateurs de chargement pour améliorer l’expérience utilisateur de votre application Web.

Polly Aide à la démystification, à la limitation et à la réessayer les demandes HTTP.

Si vous voulez en savoir plus sur le développement du blazor, vous pouvez regarder mon Cours crash gratuit du blazor sur YouTube. Et restez à l’écoute du blog Telerik pour en savoir plus Bases du blazor.