Żądanie musi być warunkowe.
Kiedy go używać
Wymaganie If-Match przy aktualizacjach, aby uniknąć utraty zapisów.
Typowe przyczyny i rozwiązania
428 informuje klienta, że serwer przyjmuje tu tylko żądania warunkowe: wyślij If-Match z ETagiem, który ostatnio odczytałeś, żeby równoległe edycje nie nadpisywały się nawzajem po cichu – to tzw. problem utraconej aktualizacji (lost update). Klient, który dostanie 428, powinien pobrać zasób GET-em, wziąć jego nagłówek ETag i ponownie wysłać PUT lub PATCH z If-Match. Jeśli do tego czasu ETag się zdezaktualizuje, odpowiedzią będzie 412.
Jako projektant API wymagaj tego tylko tam, gdzie utracone aktualizacje mają znaczenie, i udokumentuj to, bo większość klientów HTTP sama z siebie nigdy nie wysyła nagłówków warunkowych. Zwracaj bieżący ETag przy każdym GET i udanym zapisie. Proxy nie generują 428; zawsze pochodzi on z aplikacji. Upewnij się, że CDN-y i kompresja nie przepisują ETagów, bo inaczej If-Match nigdy nie zostanie spełniony.
Błąd klienta (4xx)
Kody 4xx to błędy klienta: samo żądanie jest błędne, nieautoryzowane albo wskazuje na coś, czego nie ma. Ponowienie tego samego żądania nic nie da.
Jak to wygląda
HTTP/1.1 428 Precondition RequiredJak go wysłać
| Node.js / Express | res.status(428).end() |
|---|---|
| Python / Flask | return '', 428 |
| nginx | return 428; |
Jak go sprawdzić
curl -s -o /dev/null -w "%{http_code}\n" https://example.com/