Integracja aplikacji PHP z zewnętrznym API

O czym jest ta prezentacja?

PHP jako klient API

Nowoczesne aplikacje rzadko działają w izolacji. Potrzebują danych z zewnętrznych serwisów: pogoda, kursy walut, mapy, płatności, social media. PHP może być nie tylko serwerem obsługującym requesty, ale też klientem wysyłającym requesty do innych API. W tej prezentacji wyjaśnisz jak aplikacja PHP komunikuje się z zewnętrznym API przez HTTP, jak przetwarza odpowiedzi JSON, jak się autoryzuje tokenem i jak radzi sobie z błędami i limitami (rate limiting).

Kluczowe pytania do odpowiedzi

Co to jest API? - Definicja w kontekście HTTP i JSON
Jak to działa? - Mechanizm: PHP request → API → JSON response → przetworzenie
Kiedy używać? - Dane pogodowe, waluty, geolokacja, płatności
Na co uważać? - Błędy sieci, status codes, limity, awarie API
Jak robić dobrze? - Obsługa błędów, retry, cache, bezpieczne przechowywanie tokenów

Zakres merytoryczny

Elementy obowiązkowe

Czym jest API (w kontekście HTTP)
- API = Application Programming Interface
- W webie: endpoint HTTP, który zwraca dane (najczęściej JSON)
- Przykłady: OpenWeatherMap, ExchangeRate API, Google Maps API
Request i Response
- Request: metoda (GET/POST), URL, nagłówki (Authorization), body
- Response: status code (200, 401, 429, 500), body (JSON)
- PHP: file_get_contents() lub cURL do wysyłania requestów
Autoryzacja w API
- API Key - klucz w nagłówku lub URL
- Bearer Token - token w nagłówku Authorization
- Bezpieczeństwo: nie commituj tokenów do repo!
Status codes w integracji
- 200 OK - sukces
- 401 Unauthorized - zły token
- 429 Too Many Requests - przekroczony limit
- 500 Internal Server Error - błąd po stronie API
Obsługa błędów
- Co robić gdy API nie odpowiada?
- Co robić gdy zwraca błąd?
- Fallback, cache, komunikat dla użytkownika

Wymagane elementy wizualne

Schemat przepływu

PHP → HTTP Request → Zewnętrzne API → JSON Response → Przetworzenie → Output dla użytkownika

Przykład request/response

GET /api/weather?city=Warsaw + Response JSON z danymi

Warianty realizacji

Zawartość:

Wyjaśnij ideę integracji z API - czym jest API, przepływ danych
Pokaż 1 schemat: PHP → API → JSON → wynik
Pokaż 1 przykład request/response (może być pseudo-kod)

Forma: 10 slajdów, 10 minut prezentacji

Ocena: 3.0

Struktura prezentacji

Slajd tytułowy - Tytuł, autorzy, data
Agenda - Plan prezentacji
Problem - Skąd brać dane, których nie mamy? (pogoda, waluty, mapy)
Co to jest API? - Definicja, endpoint, JSON
Schemat przepływu - PHP → API → JSON → wynik
Przykład requestu - URL, nagłówki, metoda
Przykład response - Status code, JSON body
Autoryzacja - API Key, Bearer Token
Status codes - 200, 401, 429, 500 - co znaczą
Obsługa błędów - Co robić gdy API nie działa
Dobre praktyki - Cache, retry, bezpieczeństwo tokenów
Podsumowanie i źródła

Scenariusze i przykłady

Scenariusz 1: Pobieranie danych pogodowych

Aplikacja wyświetla pogodę dla miasta. PHP wysyła request do OpenWeatherMap:

GET https://api.openweathermap.org/data/2.5/weather?q=Warsaw&appid=YOUR_KEY

API zwraca JSON z temperaturą, wilgotnością, opisem. PHP parsuje JSON i wyświetla użytkownikowi “Warszawa: 15°C, słonecznie”.

Scenariusz 2: Co gdy API nie działa?

Użytkownik wchodzi na stronę z kursami walut. Twoje API zewnętrzne nie odpowiada (timeout 30 sekund). Bez obsługi błędów - użytkownik czeka i czeka. Z obsługą:

Timeout 5 sekund
Fallback: “Kursy walut chwilowo niedostępne, spróbuj później”
Lub: pokaż ostatnie zapisane kursy z cache

Scenariusz 3: Przekroczony limit API

API darmowe ma limit 100 requestów/minutę. Twoja aplikacja jest popularna i przekracza limit. API zwraca 429 Too Many Requests. Bez obsługi - aplikacja “nie działa”. Z obsługą:

Sprawdź nagłówek Retry-After
Poczekaj i spróbuj ponownie
Lub: cache agresywniej (nie odpytuj co request, tylko co 5 minut)

Mini case study (dla wariantu C)

Przypadek: Integracja z API płatności

Aplikacja e-commerce integruje się z API płatności (np. Stripe/PayU).

Wyzwania:

Token API musi być bezpieczny (nigdy w kodzie źródłowym!)
Każdy błąd oznacza stracone pieniądze
Logi są krytyczne dla rozwiązywania sporów

Rozwiązania:

Bezpieczeństwo tokenu:
- Zmienna środowiskowa: $_ENV['PAYMENT_API_KEY']
- Plik .env dodany do .gitignore
Retry z backoff:
- Błąd 5xx? Poczekaj 1s, spróbuj ponownie
- Znowu błąd? Poczekaj 2s, spróbuj ponownie
- Max 3 próby, potem fallback
Logowanie:
- Każdy request: timestamp, user_id, amount
- Każdy response: status, transaction_id
- Każdy błąd: pełne szczegóły do debugowania
Cache:
- Status transakcji sprawdzany max raz na 5 sekund
- Lista metod płatności cache’owana na 1h

Wskazówki do wystąpienia

2-3 statusy HTTP

Pokaż konkretnie: 200 = OK, 401 = zły token, 429 = limit przekroczony.

Slajd o awarii

“Co jeśli API padnie?” - fallback, komunikat, cache. To pokazuje dojrzałość.

Prawdziwe przykłady

Pokaż prawdziwe API: OpenWeatherMap, ExchangeRate. To bardziej przekonujące.

Bezpieczeństwo tokenów

Jeden slajd: “Nigdy nie commituj tokenów do repo!” - to ważna lekcja.

Najczęstsze błędy

Błąd	Jak unikać?
Pominięcie obsługi błędów	Zawsze pokaż co robić gdy API nie odpowiada
Hardcoded API key w kodzie	Pokaż jak używać zmiennych środowiskowych
Brak wyjaśnienia status codes	401 vs 403 vs 500 - to różne problemy
Czytanie że slajdów	Znaj materiał, mów własnymi słowami
Zbyt teoretyczne podejście	Pokaż prawdziwe API i prawdziwe problemy

Zasoby

MDN: HTTP Status Codes Pełna lista kodów odpowiedzi HTTP i ich znaczenie.

PHP: file_get_contents() Najprostsza metoda do HTTP GET w PHP.

PHP: cURL Zaawansowana biblioteka do requestów HTTP w PHP.

OpenWeatherMap API Darmowe API pogodowe - świetne do nauki i testów.

Do dzieła!

Prezentacja to umiejętność zawodowa!

Integracja z zewnętrznymi API to codzienność w pracy programisty. Każda nowoczesna aplikacja korzysta z wielu serwisów: płatności, mapy, powiadomienia, social media.

Wykorzystajcie lekcje - zarejestrujcie się na darmowe API (OpenWeatherMap) i przetestujcie w praktyce!

Współpraca to klucz - podzielcie się: jedna osoba zajmuje się request/response, druga obsługą błędów i bezpieczeństwem.

Pamiętajcie: Każde API może zawieść. Planuj na wypadek awarii od początku.