Création d'une application web C# avec ASP.NET Core

Exécution de l'application par défaut

Tim commence par exécuter l'application par défaut pour illustrer ce que les développeurs obtiennent d'emblée. Une fois exécuté, le projet construit l'API, télécharge les packages NuGet nécessaires et lance une page web. Cette configuration initiale démontre la structure et les fonctionnalités de base de l'API sans aucune modification.

Interaction avec l'API

La page web qui s'ouvre est alimentée par Swagger, désormais connu sous le nom d'OpenAPI. Swagger fournit une interface conviviale pour interagir avec l'API. Elle permet aux développeurs et aux non-développeurs de comprendre et de tester facilement les points d'extrémité de l'API. Cette interface est particulièrement utile pour visualiser le fonctionnement de l'API et à des fins de documentation.

Explorer Swagger

Swagger présente les points d'extrémité disponibles dans l'API. Dans la configuration par défaut, l'un des points de terminaison préconfigurés est le point de terminaison "prévisions météorologiques". En cliquant sur ce point de terminaison et en utilisant la fonction "Try it out", les utilisateurs peuvent exécuter l'appel API et voir la réponse. Cette réponse comprend des prévisions météorologiques au format JSON, ce qui montre comment les données sont renvoyées par l'API.

Tim à 8:32 souligne que, si les données JSON brutes peuvent être difficiles à lire directement à partir du navigateur, la documentation superposée de Swagger les rend beaucoup plus digestes. La documentation fournit des informations détaillées sur le point de terminaison, y compris la méthode de requête (GET, POST, etc.), la structure des données renvoyées et tous les paramètres requis.

Documentation JSON et versionnement de l'API

Swagger génère également un fichier JSON, comme l'indique Tim à 9:10, qui documente l'API dans un format lisible par une machine. Cette documentation est essentielle pour les autres applications qui doivent interagir avec l'API, car elle décrit les points de terminaison disponibles, les schémas de données et les réponses attendues.

Tim, à 9:29, souligne l'importance de la gestion des versions dans les API. La configuration par défaut inclut un indicateur de version, ce qui laisse entrevoir la possibilité de versions multiples de l'API. La version est essentielle pour maintenir la compatibilité ascendante. Lorsque des modifications apportées à l'API risquent de perturber les clients existants, le fait de disposer de plusieurs versions permet aux développeurs d'introduire de nouvelles fonctionnalités ou des modifications sans perturber les utilisateurs actuels.

Objectif des API

Tim souligne que la plupart des applications tournent autour de la récupération, de la manipulation et de l'affichage des données. Les API servent d'intermédiaires entre l'interface utilisateur et les données sous-jacentes, fournissant un moyen sûr et efficace d'accéder aux données. Cette centralisation est cruciale pour plusieurs raisons :

1. Sécurité : Les API offrent un moyen sûr de gérer l'accès aux données. Les applications mobiles et côté client ne doivent pas se connecter directement aux bases de données afin d'éviter d'intégrer les informations d'identification de la base de données dans le code client, ce qui pose des risques de sécurité importants.

2. Abstraction : Les API font abstraction de la couche de données de l'interface utilisateur, ce qui permet à différentes applications clientes (applications mobiles, applications web, applications de bureau) d'interagir avec la même source de données sans exposer la base de données ou ses informations d'identification.

Versatilité dans différents cadres

Tim fait remarquer que les API ne se limitent pas à des cadres ou à des langages spécifiques. Par exemple, une API C# peut être accessible par des frameworks JavaScript tels qu'Angular, React ou Vue, mettant en avant les capacités multiplateformes des API.

1. Vue d'ensemble de Program.cs

Tim passe en revue Program.cs, notant qu'il construit l'application web et configure des services tels que l'injection de dépendances pour les contrôleurs et Swagger (OpenAPI). Le code met en place les services essentiels avant de construire et d'exécuter l'application.

using Microsoft.AspNetCore.Builder;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.
builder.Services.AddControllers();
// Learn more about configuring Swagger/OpenAPI at https://aka.ms/aspnetcore/swashbuckle
builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();

var app = builder.Build();

// Configure the HTTP request pipeline.
if (app.Environment.IsDevelopment())
{
    app.UseSwagger();
    app.UseSwaggerUI();
}

app.UseHttpsRedirection();

app.UseAuthorization();

app.MapControllers();

app.Run();

using Microsoft.AspNetCore.Builder;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.
builder.Services.AddControllers();
// Learn more about configuring Swagger/OpenAPI at https://aka.ms/aspnetcore/swashbuckle
builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();

var app = builder.Build();

// Configure the HTTP request pipeline.
if (app.Environment.IsDevelopment())
{
    app.UseSwagger();
    app.UseSwaggerUI();
}

app.UseHttpsRedirection();

app.UseAuthorization();

app.MapControllers();

app.Run();

2 Configuration de l'environnement

Tim explique comment les paramètres de l'environnement sont configurés dans launchSettings.json. L'environnement par défaut est défini sur "Development" pour les tests locaux, ce qui permet d'activer Swagger. En production, Swagger est généralement désactivé pour des raisons de sécurité, mais il peut être activé en supprimant le contrôle de développement.

{
  "profiles": {
    "IIS Express": {
      "commandName": "IISExpress",
      "launchBrowser": true,
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      }
    },
    "WebApplication": {
      "commandName": "Project",
      "launchBrowser": true,
      "applicationUrl": "https://localhost:5001;http://localhost:5000",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      }
    }
  }
}

3. redirection HTTPS et contrôleurs

Tim souligne la redirection HTTPS et le mappage des contrôleurs. Cette configuration permet de s'assurer que les routes API sont correctement configurées. Il préfère utiliser le préfixe "api" pour plus de clarté dans les routes de requête et de réponse HTTP, qui peuvent être modifiées pour s'assurer que les chemins d'accès à l'API sont distincts.

4 Contrôleur de prévisions météorologiques

Tim s'attaque à WeatherForecastController.cs, mettant en évidence la configuration de la route. La route par défaut est /weatherforecast, qui peut être modifiée pour inclure un préfixe "api". Le contrôleur utilise HTTP GET pour récupérer les données, auxquelles il est possible d'accéder par la route spécifiée.

using Microsoft.AspNetCore.Mvc;

[ApiController]
[Route("[controller]")]
public class WeatherForecastController : ControllerBase
{
    private static readonly string[] Summaries = new[]
    {
        "Freezing", "Bracing", "Chilly", "Cool", "Mild", "Warm", "Balmy", "Hot", "Sweltering", "Scorching"
    };

    private readonly ILogger<WeatherForecastController> _logger;

    public WeatherForecastController(ILogger<WeatherForecastController> logger)
    {
        _logger = logger;
    }

    [HttpGet]
    public IEnumerable<WeatherForecast> Get()
    {
        return Enumerable.Range(1, 5).Select(index => new WeatherForecast
        {
            Date = DateTime.Now.AddDays(index),
            TemperatureC = Random.Shared.Next(-20, 55),
            Summary = Summaries[Random.Shared.Next(Summaries.Length)]
        })
        .ToArray();
    }
}

public class WeatherForecast
{
    public DateTime Date { get; set; }

    public int TemperatureC { get; set; }

    public string? Summary { get; set; }
}

using Microsoft.AspNetCore.Mvc;

[ApiController]
[Route("[controller]")]
public class WeatherForecastController : ControllerBase
{
    private static readonly string[] Summaries = new[]
    {
        "Freezing", "Bracing", "Chilly", "Cool", "Mild", "Warm", "Balmy", "Hot", "Sweltering", "Scorching"
    };

    private readonly ILogger<WeatherForecastController> _logger;

    public WeatherForecastController(ILogger<WeatherForecastController> logger)
    {
        _logger = logger;
    }

    [HttpGet]
    public IEnumerable<WeatherForecast> Get()
    {
        return Enumerable.Range(1, 5).Select(index => new WeatherForecast
        {
            Date = DateTime.Now.AddDays(index),
            TemperatureC = Random.Shared.Next(-20, 55),
            Summary = Summaries[Random.Shared.Next(Summaries.Length)]
        })
        .ToArray();
    }
}

public class WeatherForecast
{
    public DateTime Date { get; set; }

    public int TemperatureC { get; set; }

    public string? Summary { get; set; }
}

5 Les verbes HTTP et le routage

Tim explique comment les verbes HTTP (GET, POST, PUT, DELETE) définissent les points de terminaison des API. Pour une requête GET, le navigateur appelle la méthode spécifiée dans le contrôleur. D'autres verbes font appel à des outils tels que Postman pour les tests.

API REST

Tim Corey présente REST (Representational State Transfer) et ses principes :

1. <Qu'est-ce que REST : REST est un style architectural pour la conception d'applications en réseau. Il repose sur une communication sans état et utilise des méthodes HTTP standard (GET, POST, PUT, DELETE) pour effectuer des opérations.

2. Principes RESTful : Les API RESTful utilisent des modèles d'URL pour représenter les ressources. Par exemple, /users récupère tous les utilisateurs, tandis que /users/5 récupère un utilisateur spécifique avec l'ID 5.

3. Conformité REST : Tim fait remarquer qu'il peut être difficile de parvenir à une conformité REST totale, car REST était à l'origine un modèle théorique. Toutefois, le respect des principes REST peut conduire à des API plus intuitives et plus cohérentes.

Tim insiste sur le fait que, tout en visant la conformité REST, des considérations pratiques doivent guider la conception de l'API afin de garantir la convivialité et la fonctionnalité.

Application minimale de l'API

Corey présente les API minimales, une approche rationalisée du développement d'API dans ASP.NET Core :

1. Mise en place d'API minimales : Tim montre comment créer un projet d'API minimales en décochant l'option "Utiliser des contrôleurs" lors de la mise en place du projet.

2. Code simplifié : Les API minimales éliminent le besoin de contrôleurs et d'attributs de routage, permettant aux développeurs de définir les points de terminaison directement dans Program.cs en utilisant des méthodes telles que app.MapGet(), app.MapPost(), etc.

3. Exemple de code : Tim fournit un exemple de code dans lequel une seule ligne de code définit un point de terminaison. Il montre comment faire correspondre une requête GET à un point de terminaison avec une configuration minimale.

using Microsoft.AspNetCore.Builder;
using Microsoft.Extensions.Hosting;

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.MapGet("/", () => "Hello World!");

app.Run();

using Microsoft.AspNetCore.Builder;
using Microsoft.Extensions.Hosting;

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.MapGet("/", () => "Hello World!");

app.Run();

Les API minimales sont conçues pour simplifier le développement, en particulier pour les petites applications ou les microservices.