API (Application Programming Interface) to zestaw reguł, dzięki którym programy mogą się ze sobą komunikować – jedna aplikacja wysyła żądanie, druga odpowiada danymi. Gdy logujesz się na stronie przez Google, aplikacja pogodowa pobiera prognozę, a WooCommerce przetwarza płatność przez Stripe – to wszystko dzieje się przez API. API to „kelner” między Twoją aplikacją (klient) a zewnętrznym systemem (serwer): zamawiasz dane, kelner przynosi odpowiedź. Najczęstszy typ: REST API – komunikacja przez HTTP (te same adresy URL, które wpisujesz w przeglądarce).
Jak działa API – prosty przykład
Chcesz wyświetlić pogodę na swojej stronie. Nie masz stacji meteorologicznej – ale OpenWeatherMap ma API. Twoja strona wysyła żądanie HTTP: GET https://api.openweathermap.org/data/2.5/weather?q=Warszawa&appid=TWOJ_KLUCZ. Serwer OpenWeatherMap sprawdza: klucz API (autoryzacja), parametry (miasto: Warszawa) → zwraca odpowiedź w formacie JSON:
{
"main": {
"temp": 18.5,
"humidity": 65
},
"weather": [{"description": "partly cloudy"}]
}Twoja strona parsuje JSON i wyświetla: „Warszawa: 18,5°C, częściowe zachmurzenie”. Cały proces: 50–300 ms. Użytkownik nie wie, że dane przyszły z zewnętrznego API.
REST API – standard komunikacji
REST (Representational State Transfer) to architektura API oparta na HTTP. Komunikacja przez metody HTTP:
| Metoda | Akcja | Przykład |
|---|---|---|
| GET | Pobierz dane | GET /api/posts – lista postów |
| POST | Utwórz nowy zasób | POST /api/posts – dodaj nowy post |
| PUT/PATCH | Aktualizuj zasób | PUT /api/posts/42 – edytuj post 42 |
| DELETE | Usuń zasób | DELETE /api/posts/42 – usuń post 42 |
Odpowiedzi: JSON (najczęściej) lub XML. Kody statusu HTTP: 200 (OK), 201 (Created), 400 (Bad Request), 401 (Unauthorized), 403 (Forbidden), 404 (Not Found), 500 (Server Error).
WordPress ma wbudowane REST API – pod adresem /wp-json/wp/v2/. Możesz: pobierać posty (GET /wp-json/wp/v2/posts), tworzyć posty (POST z autoryzacją), zarządzać całą stroną programowo.
Rodzaje API
REST API – najpopularniejszy. Prosty, oparty na HTTP, bezstanowy (każde żądanie jest niezależne). Standard w web development. Przykłady: API WordPressa, Stripe, Twitter, Google Maps.
GraphQL – alternatywa od Facebooka. Klient precyzyjnie określa, jakie dane chce (zamiast dostawać „wszystko” jak w REST). Jedno żądanie zamiast kilku. Przykłady: GitHub API v4, Shopify, GitHub.
WebSocket – komunikacja w czasie rzeczywistym (czat, notyfikacje, live data). Połączenie jest utrzymywane – serwer może wysyłać dane do klienta bez czekania na żądanie. Przykłady: Slack, czat na stronach, giełdy kryptowalut.
SOAP – starszy standard (XML-based). Złożony, ale z wbudowaną walidacją i bezpieczeństwem. Nadal używany w: bankowości, ubezpieczeniach, systemach enterprise.
Popularne API, z których korzysta (prawie) każda strona
Google Maps API – mapa na stronie kontaktowej, geolokalizacja, trasa dojazdu. Darmowe do 28 000 żądań/mc mapy, potem $7/1000.
Stripe / PayU / Przelewy24 API – integracja płatności na stronie lub w sklepie. WooCommerce i PrestaShop łączą się z bramkami płatności przez API.
Google Analytics / GA4 API – pobieranie danych analitycznych programowo (raporty, dashboardy).
OpenAI / Claude API – integracja AI w aplikacji (chatbot, generowanie treści, analiza).
Social media API – Facebook, Instagram, Twitter/X, LinkedIn – logowanie przez social, wyświetlanie feedu, publikacja postów.
Autoryzacja API – klucze i tokeny
Większość API wymaga autoryzacji – żeby wiedzieć, kto wysyła żądanie (i naliczać opłaty / limity).
API Key – najprostszy sposób. Dostajesz unikalny klucz (np. sk-abc123...) i dołączasz go do każdego żądania (w nagłówku lub parametrze URL). Proste, ale: klucz to „hasło” – jeśli ktoś go pozna, ma dostęp do Twojego konta API. Nigdy nie wrzucaj kluczy API do repozytorium Git – używaj zmiennych środowiskowych (.env).
OAuth 2.0 – standard autoryzacji (np. „Zaloguj się przez Google”). Użytkownik autoryzuje aplikację → aplikacja dostaje token → token pozwala na dostęp do danych użytkownika. Bezpieczniejszy od API Key (token wygasa, użytkownik może go odwołać).
JWT (JSON Web Token) – token z zakodowanymi danymi użytkownika (ID, uprawnienia, czas ważności). Serwer generuje JWT po logowaniu → klient wysyła JWT przy każdym żądaniu → serwer weryfikuje bez odpytywania bazy.
API a SEO
API nie jest bezpośrednio widoczne dla Google (bot nie crawluje endpointów API). Ale API wpływa na SEO pośrednio: aplikacje SPA (React/Next.js) pobierają treść przez API – jeśli treść nie jest prerenderowana (SSR), Google może jej nie zaindeksować. Rozwiązanie: Server-Side Rendering (Next.js) lub Static Site Generation – treść generowana na serwerze, nie przez JavaScript w przeglądarce.
WordPress REST API pozwala budować headless CMS – treść w WordPressie (backend), frontend w React/Next.js. SEO: działające, jeśli frontend robi SSR.
Najczęściej zadawane pytania
Czy mogę korzystać z API bez programowania?
Tak – narzędzia no-code/low-code integrują API bez pisania kodu. Zapier, Make (Integromat), n8n – łączą API różnych serwisów (np. „nowe zamówienie w WooCommerce → wyślij email przez Gmail API → dodaj wiersz w Google Sheets API”). WordPress: wtyczki integracyjne (np. WPForms + Mailchimp, WooCommerce + Stripe) konfigurują API klikaniem.
Czy API jest darmowe?
Zależy od usługi. Wiele API ma darmowy tier: Google Maps (28k żądań/mc), OpenAI ($5 kredytu na start), Twitter/X (1 500 tweetów/mc read). Powyżej limitu: płacisz za użycie (pay-per-use). Darmowe API bez limitów: OpenStreetMap, Wikipedia API, wiele API rządowych (dane publiczne).
Co to jest rate limiting w API?
API ogranicza liczbę żądań, które możesz wysłać w danym czasie – np. 100 żądań/minutę. Po przekroczeniu: dostajesz kod 429 Too Many Requests i musisz poczekać. Rate limiting chroni serwer przed przeciążeniem i zapewnia sprawiedliwy dostęp. Nagłówki odpowiedzi: X-RateLimit-Limit (max żądań), X-RateLimit-Remaining (ile zostało), Retry-After (kiedy spróbować ponownie).
