201 Created to kod statusu HTTP należący do grupy 2xx (odpowiedzi sukcesu), który serwer zwraca w odpowiedzi na żądanie — najczęściej POST lub PUT — informując klienta, że nowy zasób został pomyślnie utworzony. W odróżnieniu od popularniejszego kodu 200 OK, odpowiedź 201 jednoznacznie sygnalizuje nie tylko powodzenie operacji, ale i fakt powstania nowego obiektu po stronie serwera.
- Klasa: 2xx Success — żądanie zostało odebrane, zrozumiane i wykonane.
- Typowe metody HTTP: POST (tworzenie zasobu), PUT (tworzenie lub nadpisanie zasobu pod wskazanym URI).
- Nagłówek Location: serwer powinien dołączyć adres nowo utworzonego zasobu.
- Zastosowanie: API REST, formularze rejestracyjne, systemy CMS, e-commerce.
Jak działa kod 201 Created w praktyce?
Kiedy klient (przeglądarka, aplikacja mobilna lub inny serwis) wysyła żądanie HTTP POST do API — na przykład tworząc nowe konto użytkownika — serwer przetwarza dane i, jeśli operacja się powiedzie, odpowiada właśnie kodem 201. Do odpowiedzi dołączany jest nagłówek Location wskazujący URI nowo powstałego zasobu, np. Location: /users/4821. Dzięki temu klient wie dokładnie, gdzie znaleźć świeżo utworzony obiekt — bez konieczności wykonywania dodatkowego żądania GET.
Przykładowa wymiana komunikatów wygląda tak:
- Żądanie:
POST /api/productsz danymi nowego produktu w ciele (JSON, form-data). - Odpowiedź serwera:
HTTP/1.1 201 Created+Location: /api/products/987+ opcjonalnie pełna reprezentacja zasobu w ciele odpowiedzi.
201 Created a inne kody z grupy 2xx — czym się różnią?
Kody 2xx mówią ogólnie “sukces”, ale każdy niesie inną informację semantyczną. Poniższa tabela porządkuje najczęściej mylone przypadki:
| Kod | Nazwa | Kiedy stosować? |
|---|---|---|
200 OK | OK | Żądanie GET, PUT lub DELETE zakończyło się sukcesem; zasób istniał wcześniej. |
201 Created | Created | Nowy zasób został właśnie utworzony (POST/PUT). |
202 Accepted | Accepted | Żądanie przyjęte do przetwarzania, ale jeszcze nieukończone (operacje asynchroniczne). |
204 No Content | No Content | Sukces, ale serwer nie zwraca żadnego ciała odpowiedzi (np. po DELETE). |
Kiedy serwer powinien zwrócić 201, a kiedy 200?
Zasada jest prosta: jeśli operacja skutkuje powstaniem nowego zasobu po stronie serwera, właściwą odpowiedzią jest 201. Jeśli zasób istniał wcześniej i tylko go zaktualizowano lub zwrócono, wystarczy 200. Błąd polega na zwracaniu zawsze 200 z API REST — technicznie działa, ale pozbawia klientów precyzyjnej informacji o stanie systemu i utrudnia debugowanie oraz integracje z zewnętrznymi usługami.
Znaczenie kodu 201 dla SEO i widoczności strony
Sam kod 201 nie wpływa bezpośrednio na pozycjonowanie stron, bo Googlebot nie indeksuje odpowiedzi POST — te żądania są z założenia poza zakresem crawlowania. Znaczenie pojawia się jednak pośrednio: poprawnie zaprojektowane API zwracające 201 wraz z nagłówkiem Location ułatwia budowanie linkowanych, kanonicznych adresów URL dla nowo tworzonych zasobów. Kiedy nowy produkt w sklepie internetowym lub nowy artykuł w CMS otrzymuje od razu właściwy, stały URL, zmniejsza się ryzyko powstawania duplikatów treści i problemów z przekierowaniami.
Przy pozycjonowaniu sklepów internetowych opartych na własnych API (headless commerce, PWA) precyzyjne kody statusu — w tym 201 — są elementem technicznego fundamentu, który weryfikuje audyt SEO. Błędnie skonfigurowane API może tu generować problemy z duplikatami lub niekanoniczymi URL-ami, co bezpośrednio uderza w widoczność w wyszukiwarce.
FAQ — najczęstsze pytania o kod 201 Created
Czy ciało odpowiedzi 201 jest obowiązkowe?
Nie jest obowiązkowe, ale jest zalecane. Specyfikacja RFC 9110 (dawniej RFC 7231) dopuszcza pustą odpowiedź, jednak zwrócenie reprezentacji nowo utworzonego zasobu (np. obiektu JSON z nadanym id) oszczędza klientowi konieczności wykonania kolejnego żądania GET. W praktyce większość dobrze zaprojektowanych API zwraca pełen obiekt w ciele odpowiedzi 201.
Czy 201 może wystąpić przy żądaniu GET?
Technicznie specyfikacja HTTP nie wyklucza tego sztywno, ale semantycznie jest to niepoprawne. GET jest metodą bezpieczną i idempotentną — nie powinno tworzyć zasobów. Zwrócenie 201 w odpowiedzi na GET to błąd projektowy API, który dezorientuje klientów i narzędzia diagnostyczne.
Co powinien zawierać nagłówek Location przy 201?
Nagłówek Location powinien zawierać pełny, bezwzględny URI nowo utworzonego zasobu, np. https://example.com/api/orders/5501. Użycie względnego URL jest dopuszczalne, ale bezwzględny adres eliminuje niejednoznaczności po stronie klienta — szczególnie przy złożonych środowiskach z load balancerami lub wieloma domenami.
Czym różni się 201 Created od 202 Accepted?
Kod 201 oznacza, że zasób już istnieje — operacja zakończyła się w momencie wysyłki odpowiedzi. Kod 202 informuje, że żądanie zostało przyjęte do kolejki, ale przetwarzanie jeszcze trwa (np. generowanie raportu, wysyłka e-maili wsadowych). Przy 202 klient musi mieć osobny mechanizm sprawdzenia, czy i kiedy operacja dobiegła końca.
Kod 201 — mały detal, duże znaczenie w architekturze systemu
Precyzyjne stosowanie kodu 201 Created to jeden z tych technicznych detali, który odróżnia solidnie zaprojektowane API od prowizorki działającej “jakoś”. Poprawna semantyka HTTP ułatwia integracje, monitoring i debugowanie — a w kontekście aplikacji webowych wpływa też na jakość techniczną, którą ocenia m.in. audyt SEO. Jeśli Twój sklep lub serwis oparty jest na własnym API i chcesz mieć pewność, że warstwa techniczna nie blokuje widoczności w Google, eksperci Webiti chętnie to zweryfikują.
