HTTP 200 to dopiero początek

01 / Co właściwie zostało wykonane

Agent wysyła artykuł do systemu zarządzania treścią, czyli CMS-u. Otrzymuje odpowiedź 200 i melduje sukces. Redaktor otwiera stronę: tytuł jest nowy, ale powiązanie z odcinkiem pozostało stare. Albo wszystko wygląda dobrze w panelu, lecz czytelnik widzi poprzednią wersję. To dwa różne problemy, których sam kod odpowiedzi nie rozstrzyga.

Według RFC 9110, sekcja 15.3.1, 200 oznacza powodzenie żądania; znaczenie treści odpowiedzi zależy od metody. Nie sprowadzamy tego do samego „połączenie działa”. Jednak wadliwa aplikacja może źle zrealizować lub zbyt optymistycznie opisać operację. Odbiór biznesowy wymaga dowodu, że osiągnięto oczekiwany stan.

Przyjmij cztery oddzielne pytania: czy odpowiedź opisuje sukces, czy wartości utrwalono, czy inne dane pozostały poprawne i czy docelowy widok pokazuje właściwy materiał. Zasób adaptuje metodę z historycznego audytu integracji. Nie jest aktualnym raportem usterek żadnej witryny.

02 / Najpierw określ oczekiwany stan

Przed zapisem zachowaj stan obiektu i zapisz listę zamierzonych zmian. W naszym fikcyjnym przykładzie artykuł ma identyfikator demo-article-1, status draft, tytuł „Version A”, dwie kategorie i powiązanie z demo-episode-1. Chcemy zmienić tytuł na „Version B” oraz powiązanie na demo-episode-2. Status, identyfikator i kategorie mają pozostać bez zmian.

{
  "change": {"title": "Version B", "episode_id": "demo-episode-2"},
  "preserve": {"id": "demo-article-1", "status": "draft", "categories": ["science", "workshop"]}
}

To model dydaktyczny, nie gotowe żądanie WordPressa. W dokumentacji wpisów WordPress REST API występują oddzielne operacje odczytu i aktualizacji oraz pola o określonych typach. Własne pola instalacji wymagają własnego kontraktu. Nie kopiuj wymyślonych nazw i tekstowych identyfikatorów z ćwiczenia do produkcyjnego API.

Dla każdego pola rozstrzygnij znaczenie pominięcia, pustej listy, pustego tekstu i null. Nie zakładaj, że wszystkie oznaczają „zostaw bez zmian”. Sprawdź, czy zapisujesz własny szkic oraz czy konto ma uprawnienia do tej operacji. Test przeprowadź na oznaczonym obiekcie technicznym, nie na opublikowanym materiale redakcji.

03 / Odczyt musi być osobnym krokiem

Odpowiedź na zapis może zawierać jedynie echo przesłanych danych. Nie porównuj więc wysłanego tytułu wyłącznie z odpowiedzią tego samego żądania. Odczytaj obiekt ponownie, sprawdź jego typ i identyfikator, a potem porównaj utrwalone wartości z oczekiwanymi.

Kontrola obejmuje także pola, których nie zamierzano zmieniać. Jeśli tytuł i odcinek są poprawne, lecz zniknęła jedna kategoria, cały zapis nie przeszedł odbioru. Zapis „częściowo wykonany” jest uczciwszy niż zielone „gotowe”. Nie maskuj rozbieżności wyświetleniem lokalnej kopii tego, co zamierzałeś wysłać.

Schemat odpowiedzi nie jest dowodem działania zapisu. Dokumentacja rozszerzania WordPress REST API rozdziela opis pola, jego odczyt i funkcję aktualizacji. Konkretna instalacja może mieć dodatkowe reguły i uprawnienia; trzeba je sprawdzić, zamiast przypisywać zachowanie wtyczki całemu WordPressowi.

04 / Uruchom pięć lokalnych prób

Pobierz demonstrację Python. Skrypt korzysta tylko z biblioteki standardowej, tworzy tymczasowy plik JSON i odczytuje go osobno po zapisie. Nie łączy się z siecią, nie potrzebuje konta ani klucza i nie uruchamia CMS-u. Po zakończeniu usuwa własny katalog tymczasowy. Pole http_status jest fikcyjną wartością w obiekcie, nie wynikiem prawdziwego połączenia HTTP.

python cms-readback-demo.py

Wykonano pięć prób 25 września 2026 r. Wszystkie testy przeszły, co oznacza, że kontroler demonstracyjny przyjął poprawny przypadek i wykrył cztery celowo wprowadzone problemy:

• Poprawny zapis: nowy tytuł i odcinek, zachowany identyfikator, status i kategorie — przyjęty.
• Zignorowane pole: odpowiedź potwierdza żądanie, ale utrwalony odcinek jest stary — wykryta różnica episode_id.
• Zmiana uboczna: nowe pola się zapisały, lecz kategorie zastąpiono inną listą — wykryta niezamierzona zmiana.
• Błąd wewnątrz 200: odpowiedź ma pole error mimo kodu 200 — brak zgody na sukces.
• Inny obiekt: odczyt ma poprawne nowe wartości, ale inny identyfikator — odrzucony.

To rzeczywisty wynik uruchomienia modelu dydaktycznego, nie pomiar niezawodności WordPressa. Skrypt nie testuje autoryzacji, sieci, pamięci podręcznej, współbieżności ani renderowania. Nie należy wstawiać go bezpośrednio jako klienta produkcyjnego. Pole błędu i format odpowiedzi w realnej integracji trzeba walidować według jej kontraktu.

05 / Ponów odczyt, nie mnożenie obiektów

Jeżeli odczyt pokazuje starą wartość, ograniczone ponowienia mogą pomóc ustalić, czy stan dopiero się aktualizuje. Zapisz liczbę prób i limit czasu. Utrzymująca się różnica pozostaje błędem do wyjaśnienia; nie ukrywaj jej przez niekończące się oczekiwanie.

Timeout zapisu może oznaczać, że odpowiedź nie dotarła, choć obiekt powstał. Przed powtórzeniem tworzenia odnajdź wynik po trwałym identyfikatorze operacji lub użyj mechanizmu idempotencji, jeśli system rzeczywiście go obsługuje. Nie dopisuj dowolnego nagłówka z założeniem, że serwer zapewni jego działanie. Przy nieznanym skutku operacji wstrzymaj dalszy zapis i ustal stan.

Odczyt przed aktualizacją nie rozwiązuje sam wyścigu z innym redaktorem. Jeśli ktoś zmienił obiekt po twoim odczycie, ponowne wysłanie całej starej kopii może cofnąć jego pracę. Potrzebna jest kontrola wersji lub warunek aktualizacji wspierany przez API. Bez takiego mechanizmu ogranicz zakres zmiany i uzgodnij sposób obsługi konfliktu. Nie traktuj automatycznego przywrócenia starego stanu jako zawsze bezpiecznej naprawy.

06 / Panel i strona publiczna to dwa odbiory

Poprawny rekord w CMS-ie nie gwarantuje poprawnego widoku. Strona może używać innego pola, starej pamięci podręcznej albo nieprawidłowego adresu. Po autoryzowanej publikacji sprawdź docelowy URL oraz treść, nie tylko kod 200. Strona logowania czy komunikat błędu również mogą zostać zwrócone w poprawnej odpowiedzi HTTP.

Odbiór obejmuje tytuł, lead, treść, podpisy, ilustrację, opis alternatywny i powiązania. Przy odtwarzaczu sprawdź rzeczywiste odtwarzanie właściwego materiału, nie samą obecność ramki. Natywny komponent CMS-u nie musi używać iframe; test powinien sprawdzać funkcję, a nie jedną wybraną konstrukcję HTML.

Oddziel adres panelu, publiczny adres i wskazanie canonical. Potwierdź, że odsyłają do właściwego materiału. Sprawdź metadane karty społecznościowej i dane uporządkowane, jeśli są częścią uzgodnionego zakresu. Nie dopisuj nieistniejących informacji tylko po to, by walidator pokazał komplet pól. Wygląd i działanie odbierz na szerokim oraz wąskim ekranie. Podgląd szkicu nie zastępuje odrębnego odbioru strony po publikacji.

07 / Lista zamknięcia integracji

• Cel i zgoda: właściwe środowisko, obiekt, status i zakres działania; publikacja oddzielona od zapisu szkicu.
• Kontrakt: typy, pola wymagane, pominięcia i czyszczenie wartości sprawdzone na własnym obiekcie testowym.
• Zapis: poprawna odpowiedź według kontraktu, bez ukrytego błędu aplikacji.
• Odczyt: tożsamość obiektu i wszystkie zmieniane pola potwierdzone w osobnej operacji.
• Skutki uboczne: zachowane pola i relacje, obsłużony konflikt wersji, brak niezamierzonego duplikatu.
• Widok: docelowy materiał, media, adresy i uzgodnione metadane sprawdzone w przeglądarce.
• Dowód: czas, wersja klienta, identyfikator operacji, oczekiwany i odczytany stan oraz lista rozbieżności; bez sekretów w logu.
• Zakończenie: obiekt techniczny usunięty lub przeniesiony do kosza zgodnie z planem, a jego końcowy stan sprawdzony. Nie usuwaj obiektu, którego własności nie ustalono.

Odbiór jednej operacji nie potwierdza całej integracji. Utworzenie szkicu, jego aktualizacja, przypisanie medium i publikacja to osobne przypadki. Uprawnienie do korzystania z obrazu nie oznacza prawa do zmiany jego metadanych we wszystkich artykułach. Przechowuj oddzielne identyfikatory artykułu, serii, odcinka i zewnętrznego nagrania.

08 / Źródła i granice dowodu

Przeczytano pełny wewnętrzny raport integracji z 15 września 2026 r. Wydanie wykorzystuje jego metodę: stan przed zmianą, osobny odczyt, rozróżnienie deklaracji od testu i kontrolę końcowego widoku. Prywatne konta, adresy paneli, identyfikatory i katalog usterek konkretnego serwisu nie są częścią publicznego przykładu. Nie sprawdzano ponownie obecnej produkcji tego serwisu.

Dokumentację HTTP i WordPressa wskazaną w tekście sprawdzono 25 września 2026 r. Objaśnia mechanizmy; nie dowodzi działania własnych pól konkretnej instalacji. Lokalny test obejmuje pięć opisanych przypadków fikcyjnego magazynu JSON. Prawdziwy CMS wymaga odrębnego odbioru na kontrolowanych obiektach.

Tekst PL/EN, schemat i kod demonstracji przygotował Codex. Przeprowadzono odbiór autorski, bez niezależnej recenzji drugiego modelu. Udział SI jest jawny; człowiek może wycofać to wydanie po publikacji. Zmiana kontraktu, wykryty błąd demonstracji lub istotna zmiana dokumentacji są wyzwalaczami korekty.