Tworzenie aplikacji webowej C# za pomocą ASP.NET Core

Uruchamianie aplikacji domyślnej

Tim zaczyna od uruchomienia domyślnej aplikacji, aby pokazać, co programiści otrzymują od razu po uruchomieniu. Po uruchomieniu projekt tworzy API, pobiera niezbędne pakiety NuGet i otwiera stronę internetową. Ta wstępna konfiguracja pokazuje podstawową strukturę i funkcjonalność API bez żadnych modyfikacji.

Interakcja z API

Uruchamiana strona internetowa jest oparta na Swaggerze, znanym obecnie jako OpenAPI. Swagger zapewnia przyjazny dla użytkownika interfejs do interakcji z API. Pozwala to zarówno programistom, jak i osobom niebędącym programistami na łatwe zrozumieniuiuiuiuie i przetestowanie punktów końcowych API. Interfejs ten jest szczególnie przydatny do wizualizacji działania API oraz do celów dokumentacyjnych.

Odkrywanie Swagger

Swagger prezentuje dostępne punkty końcowe w API. W domyślnej konfiguracji jednym z wstępnie skonfigurowanych punktów końcowych jest punkt końcowy "prognoza pogody". Klikając ten punkt końcowy i korzystając z funkcji "Wypróbuj", użytkownicy mogą wykonać wywołanie API i zobaczyć odpowiedź. Ta odpowiedź zawiera prognozę pogody w formacie JSON, pokazującą, w jaki sposób dane są zwracane przez API.

Tim o godz. 8:32 podkreśla, że chociaż surowe dane JSON mogą być trudne do odczytania bezpośrednio w przeglądarce, nakładka dokumentacji Swagger sprawia, że są one znacznie bardziej przystępne. Dokumentacja zawiera szczegółowe informacje na temat punktu końcowego, w tym metodę żądania (GET, POST itp.), strukturę zwracanych danych oraz wszelkie wymagańe parametry.

Dokumentacja JSON i wersjonowanie API

Swagger generuje również plik JSON, jak wskazuje Tim o 9:10, który dokumentuje API w formacie nadającym się do odczytu maszynowego. Dokumentacja ta ma kluczowe znaczenie dla innych aplikacji, które muszą współpracować z API, ponieważ opisuje dostępne punkty końcowe, schematy danych i oczekiwane odpowiedzi.

Tim o godz. 9:29 zwraca uwagę na znaczenie wersjonowania w interfejsach API. Domyślna konfiguracja zawiera wskaźnik wersji, co sugeruje możliwość istnienia wielu wersji API. Wersjonowanie ma kluczowe znaczenie dla zachowania kompatybilności wstecznej. Gdy zmiany w API mogą spowodować awarię istniejących klientów, posiadanie wielu wersji pozwala programistom na wprowadzanie nowych funkcji lub zmian bez zakłócania pracy obecnych użytkowników.

Cel interfejsów API

Tim podkreśla, że większość aplikacji skupia się na danych — ich pobieraniu, przetwarzaniu i wyświetlaniu. Interfejsy API pełnią rolę pośredników między interfejsem użytkownika a danymi bazowymi, zapewniając bezpieczny i wydajny sposób dostępu do danych. Ta centralizacja ma kluczowe znaczenie z kilku powodów:

1. Bezpieczeństwo: Interfejsy API zapewniają bezpieczny sposób zarządzania dostępem do danych. Aplikacje mobilne i po stronie klienta nie powinny łączyć się bezpośrednio z bazami danych, aby uniknąć umieszczania danych uwierzytelniających do bazy danych w kodzie klienta, co stwarza poważne zagrożenie dla bezpieczeństwa.

2. Abstrakcja: Interfejsy API oddzielają warstwę danych od interfejsu użytkownika, umożliwiając różnym aplikacjom klienckim (aplikacjom mobilnym, internetowym, desktopowym) interakcję z tym samym źródłem danych bez ujawniania bazy danych lub jej danych uwierzytelniających.

Wszechstronność w różnych frameworkach

Tim zauważa, że interfejsy API nie są ograniczone do konkretnych frameworków lub języków. Na przykład dostęp do interfejsu API języka C# mogą uzyskać frameworki JavaScript, takie jak Angular, React lub Vue, co pokazuje możliwości międzyplatformowe interfejsów API.

1. Omówienie pliku Program.cs

Tim przegląda plik Program.cs, zauważając, że służy on do tworzenia aplikacji internetowej i konfiguracji usług, takich jak wstrzykiwanie zależności dla kontrolerów oraz Swagger (OpenAPI). Kod konfiguruje niezbędne usługi przed kompilacją i uruchomieniem aplikacji.

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. Konfiguracja środowiska

Tim wyjaśnia, jak są konfigurowane ustawienia środowiska w launchSettings.json. Domyślne środowisko jest ustawione na "Development" do lokalnego testowania, z włączoną obsługą Swagger. W środowisku produkcyjnym Swagger jest zazwyczaj wyłączony ze względów bezpieczeństwa, ale można go włączyć, usuwając znacznik "development".

{
  "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. Przekierowanie HTTPS i kontrolery

Tim zwraca uwagę na przekierowanie HTTPS i mapowanie kontrolerów. Ta konfiguracja zapewnia prawidłowe skonfigurowanie tras API. Autor preferuje stosowanie przedrostka "api" dla przejrzystości w trasach żądań i odpowiedzi HTTP, co można zmodyfikować, aby zapewnić rozróżnienie ścieżek API.

4. Kontroler prognozy pogody

Tim zagłębia się w WeatherForecastController.cs, podkreślając konfigurację trasy. Domyślna trasa to /weatherforecast, którą można zmodyfikować, aby uwzględniała przedrostek 'api'. Kontroler wykorzystuje metodę HTTP GET do pobierania danych, do których dostęp można uzyskać poprzez określoną trasę.

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. Czasowniki HTTP i routing

Tim wyjaśnia, w jaki sposób czasowniki HTTP (GET, POST, PUT, DELETE) definiują punkty końcowe API. W przypadku żądania GET przeglądarka wywołuje określoną metodę w kontrolerze. Inne czynności wymagają narzędzi takich jak Postman do testowania.

REST API

Tim Corey przedstawia REST (Representational State Transfer) i jego zasady:

1. Czym jest REST: REST to styl architektury służący do projektowania aplikacji sieciowych. Opiera się na komunikacji bezstanowej i wykorzystuje standardowe metody HTTP (GET, POST, PUT, DELETE) do wykonywania operacji.

2. Zasady RESTful: Interfejsy API RESTful wykorzystują wzorce adresów URL do reprezentowania zasobów. Na przykład, /users pobiera wszystkich użytkowników, podczas gdy /users/5 pobiera konkretnego użytkownika o identyfikatorze 5.

3. Zgodność z REST: Tim zauważa, że osiągnięcie pełnej zgodności z REST może być trudne, ponieważ REST był pierwotnie modelem teoretycznym. Jednak przestrzeganie zasad REST może prowadzić do bardziej intuicyjnych i spójnych interfejsów API.

Tim podkreśla, że dążąc do zgodności z REST, przy projektowaniu API należy kierować się względami praktycznymi, aby zapewnić użyteczność i funkcjonalność.

Aplikacja z minimalnym API

Corey przedstawia Minimal APIs, uproszczone podejście do tworzenia interfejsów API w .NET Core:

1. Konfiguracja minimalnych interfejsów API: Tim pokazuje, jak utworzyć projekt z minimalnym interfejsem API, odznaczając opcję "Użyj kontrolerów" podczas konfiguracji projektu.

2. Uproszczony kod: Minimalne API eliminują potrzebę stosowania kontrolerów i atrybutów routingu, pozwalając programistom definiować punkty końcowe bezpośrednio w Program.cs za pomocą metod takich jak app.MapGet(), app.MapPost(), itp.

3. Przykład kodu: Tim podaje przykład kodu, w którym pojedynczy wiersz kodu definiuje punkt końcowy. Pokazuje, jak przypisz żądanie GET do punktu końcowego przy minimalnej konfiguracji.

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();

Minimalne interfejsy API mają na celu uproszczenie programowania, zwłaszcza w przypadku mniejszych aplikacji lub mikrousług.