Dodawanie spowolnień i kodów błędów — kurs tworzenia przykładowego interfejsu API w języku C#

Wprowadzenie do przykładowego API i jego celu

Tim rozpoczyna lekcję, podkreślając wartość posiadania przykładowego API podczas nauki tworzenia stron internetowych. Takie API daje ci coś konkretnego, aby testować swoje front-endowe aplikacje.

Do końca kursu Tim zamierza zbudować solidne API, które obejmuje:

• Przykładowe dane

• Dokumentację

• Sprawdzenia zdrowia

• Symulowane opoźnienia

• Symulowane błędy

• Opcje wdrożenia przez Docker i VPS

W tej konkretnej lekcji Tim koncentruje się na symulacji opoźnień i generowaniu kodów błędów dla realistycznego zachowania API w trudnych warunkach.

Dodawanie sztucznych opoźnień do punktów końcowych API

Tim zaczyna, dodając opcjonalny parametr opoźnienia do konkretnych punktów końcowych API — szczególnie tych dotyczących danych kursu. Jego celem jest symulowanie wolnych odpowiedzi API, aby lepiej testować front-end.

if (delay > 300000)
{
    delay = 300000;
}
await Task.Delay(delay.Value);

if (delay > 300000)
{
    delay = 300000;
}
await Task.Delay(delay.Value);

Testowanie mechanizmu opoźnienia

Tim wykonuje kilka testów za pomocą Postman (lub klona Postman), aby zweryfikować logikę opoźnienia. Na przykład:

• Opoźnienie=5000 (5 sekund) powoduje, że API się pauzuje przed zwróceniem wyników.

• Opoźnienie=500 efektywnie powoduje krótszą pauzę.

Obserwuje, że rzeczywiste opoźnienie będzie zawsze nieco dłuższe niż podana wartość z powodu obciążenia przetwarzania — ważna rzeczywista subtelność. Jak zauważa Tim na 5:09, nie mierzysz API co do milisekundy, ale raczej symulujesz prog.

Rozszerzanie funkcjonalności opoźnienia na więcej punktów końcowych

Tim nie zatrzymuje się tylko na punkcie końcowym "załaduj wszystkie kursy". Chce spójności, więc implementuje tę samą zdolność opoźnienia w punkcie końcowym "załaduj kurs przez ID".

Na 6:15, napotyka problem: konflikt nazw z powodu automatycznego dodania "Async" do nazwy metody podczas przekształcania na asynchroniczną. Tim dostosowuje obie nazwy metod, aby dostosować je do konwencji nazewniczej Async dla przejrzystości i spójności.

Testowanie potwierdza implementację:

• Opoźnienia są respektowane.

• Nieistniejące rekords zwracają 404 zgodnie z oczekiwaniami po opoźnieniu.

• Usunięcie opoźnienia lub przekazanie pustych wartości zachowuje się odpowiednio, Tim zauważa jednak pewną anomalię interfejsu użytkownika w Postman, a nie z API samym w sobie (8:00).

code switch
{
    400 => Results.BadRequest(),
    401 => Results.Unauthorized(),
    403 => Results.Forbid(),
    404 => Results.NotFound(),
    _   => Results.StatusCode(code)
};

code switch
{
    400 => Results.BadRequest(),
    401 => Results.Unauthorized(),
    403 => Results.Forbid(),
    404 => Results.NotFound(),
    _   => Results.StatusCode(code)
};

Testowanie punktu końcowego błędów

Tim teraz testuje punkt końcowy, przekazując różne kody statusu:

• 400 zwraca "Złe żądanie"

• 401 zwraca "Nieautoryzowany"

• 404 zwraca "Nie znaleziono"

• 301 zwraca "Trwale przeniesiony"

• 405 zwraca "Metoda niedozwolona"

Pokazuje to elastyczność punktu końcowego — nie tylko dla kodów błędów, ale dla dowolnego kodu statusu HTTP. Na 13:04, Tim potwierdza, że to podejście jest idealne do testowania, jak front-endowe aplikacje obsługują różne odpowiedzi serwera.

Rozważał nazwanie go /httpcode, ale utrzymał /error dla prostoty, jako że jest on przede wszystkim używany do symulacji warunków błędów.

Podsumowanie ulepszeń funkcjonalnych

Tim kończy wideo, podsumowując ulepszenia wprowadzone do API:

• Opoźnienia symulują rzeczywiste opoźnienia w odpowiedziąch API.

• Symulacja błędów zapewnia elastyczność testowania praktycznie każdej odpowiedzi HTTP.

• Te funkcje sprawiają, że przykładowe API jest bardziej solidne i wartościowe dla realistycznych scenariuszy testowania.

Na 14:16, Tim podkreśla znaczenie tych narzędzi do testowania, jak aplikacja zachowuje się w różnych stanach API, takich jak opoźnione odpowiedzi czy różne błędy serwera.

Co dalej: Dockerization API

Chociaż nie opisano tego szczegółowo w tym wideo, Tim sugeruje kolejny krok: Dockerization API. To pozwala programistom uruchamiać przykładowe API lokalnie w samodzielnym kontenerze Docker, co ułatwia wdrażanie i udostępnianie w różnych środowiskach.

Podsumowanie

Tim kończy wideo, ponownie podkreślając swoje zaangażowanie w tworzenie kompleksowego przykładowego API, które obejmuje realistyczne funkcje, których programiści naprawdę potrzebują do testowania. Obejmują one:

• Opoźnienia

• Błędy

• Sprawdzenia zdrowia

• Plany na przyszłość dotyczące uwierzytelniania i zaawansowanych punktów końcowych

Cel jest prosty, ale potężny — wyposażenie deweloperów w narzędzie, które naśładuje kaprysy prawdziwych API, dzięki czemu ich aplikacje są solidne, niezawodne i przyjazne dla użytkownika.

Wnioski

Do końca tej lekcji widzowie zyskują lepsze zrozumieniuiuiuiuie, jak i dłączego wprowadzać sztuczne opoźnienia i odpowiedzi błędów w swoich API. Podejście Tima Corey'a jest metodyczne, praktyczne i bezpośrednio związane z potrzebami testowania rzeczywistych aplikacji. Jeśli szukasz sposobu, aby wzmocnić swoje testy API, ta lekcja jest doskonałym zasobem do naśladowania — a teraz dokładnie wiesz, gdzie szukać.

Obejrzyj pełną lekcję wideo Tima Corey, aby uzyskać praktyczne wskazówki.