WordPress REST API i WPGraphQL: jak wybrać interfejs danych

JSON opisuje sposób zapisu danych: obiektów, tablic, tekstów czy liczb. Sam format nie określa, jak wygląda adres zasobu, które pola są wymagane ani jak zwrócić błąd. Dwa systemy używające JSON mogą mieć zupełnie inne kontrakty. Dlatego przed wyceną integracji potrzebna jest dokumentacja obu stron, a nie tylko nazwa formatu.

JSON:API to odrębna specyfikacja organizacji żądań i odpowiedzi. Nie należy jej utożsamiać z dowolnym interfejsem zwracającym JSON. WordPress REST API ma własne endpointy, parametry i strukturę odpowiedzi. Jeżeli integracja wymaga zgodności z JSON:API, trzeba sprawdzić konkretną implementację lub warstwę pośrednią.

Standardowy adres wpisów WordPressa zawiera `/wp-json/wp/v2/posts`. Brak ładnych odnośników nie wyklucza API: dokumentacja tras i endpointów wskazuje dostęp przez parametr `rest_route`. Trasa identyfikuje zasób, natomiast obsługiwany endpoint zależy również od metody HTTP. Odczyt i usunięcie danych nie są tym samym działaniem tylko dlatego, że korzystają z podobnego adresu.

W planie automatyzacji i integracji zapisz zasoby, kierunek wymiany, częstotliwość oraz zasady błędów. To pozwala ocenić interfejs na podstawie potrzeb procesu.

WordPress REST nie musi zwracać całego obiektu, jeżeli aplikacja potrzebuje tylko identyfikatora i tytułu. Parametr `_fields` pozwala wskazać potrzebne pola odpowiedzi. Przykładowa ścieżka odczytu to `/wp-json/wp/v2/posts?_fields=id,title`. To przykład struktury żądania, nie potwierdzenie wyniku na dowolnej instalacji: endpoint może mieć dodatkowe pola lub ograniczenia.

Parametr `_embed` pozwala osadzać dane wybranych powiązanych zasobów, jeśli dana relacja obsługuje osadzanie. Nie oznacza dowolnego łączenia całej bazy. Przy wspólnym użyciu `_fields` i `_embed` trzeba uwzględnić wymagane pola związane z relacjami, zgodnie z dokumentacją parametrów globalnych. Sprawdź rzeczywistą odpowiedź zamiast zakładać, że sam parametr skróci każde zapytanie.

Zachowaj stronicowanie i kontroluj liczbę rekordów. Pobieranie wszystkich wpisów przy każdym otwarciu ekranu jest innym problemem niż wielkość pojedynczego obiektu. Ustal, które dane mogą być odświeżane okresowo, a które wymagają bieżącej odpowiedzi. Cache powinien uwzględniać parametry zapytania, język i uprawnienia. Odpowiedzi prywatnej nie wolno potraktować jak publicznej listy wpisów tylko dlatego, że obie mają format JSON.

WPGraphQL udostępnia schemat, w którym klient wskazuje potrzebne pola i powiązania. Może to ułatwić budowę interfejsu łączącego kilka rodzajów treści. Dokumentacja WPGraphQL opisuje to podejście jako dodatkowy interfejs dla WordPressa. Trzeba jednak potwierdzić, czy schemat obejmuje używane pola niestandardowe, rozszerzenia i wymagane operacje.

Jedno żądanie HTTP nie oznacza jednego zapytania do bazy. Zagnieżdżone relacje mogą wymagać wielu operacji po stronie serwera. Problem N+1 nie znika automatycznie po zmianie REST na GraphQL. Oceniaj czas i koszt wykonania, sposób buforowania oraz ograniczenia złożoności zapytań. Tak samo REST z dobrze dobranymi polami może wystarczyć bez dokładania nowej zależności.

Do porównania wybierz rzeczywisty ekran lub proces, na przykład listę artykułów z autorami. Spisz wymagane dane, sprawdź sposób ich uzyskania w obu modelach i oceń obsługę błędów. Następnie dolicz utrzymanie rozszerzeń, aktualizacje schematu i kompetencje zespołu. Wbudowany REST również wymaga utrzymania kontraktu; obecność w rdzeniu nie usuwa kosztu własnego kodu. Przy wdrożeniu WordPressa interfejs powinien odpowiadać potrzebom odbiorców danych, a nie modzie na konkretną technologię.

Wpisy i strony to nie to samo co zamówienia, płatności oraz dane klientów. Nie zakładaj, że każdy zasób sklepu jest publiczną częścią wp/v2. WooCommerce ma własne interfejsy, w tym REST API do zastosowań administracyjnych i integracyjnych oraz Store API obsługujące określone scenariusze sklepu. Dokładny zakres i uwierzytelnianie trzeba sprawdzić w dokumentacji używanego endpointu i wersji.

W integracji ustal, kto jest właścicielem stanu magazynowego, ceny i statusu realizacji. Samo pobranie JSON nie zapewnia synchronizacji. Potrzebne są identyfikatory, obsługa ponowienia, wykrywanie konfliktów i zasady przetwarzania danych osobowych. Błąd sieci po zapisie nie dowodzi, że operacja się nie wykonała. Ponowienie bez kontroli może stworzyć duplikat.

Headless WordPress rozdziela CMS od prezentacji. Może korzystać z REST albo WPGraphQL, lecz wybór API sam nie wymusza przebudowy całej witryny. Tradycyjna strona internetowa może udostępniać pojedynczy zasób zewnętrznemu systemowi. Przy osobnym frontendzie trzeba zaplanować także podgląd redakcyjny, publikację, formularze i utrzymanie obu aplikacji. To koszt architektury, którego nie widać w prostym porównaniu liczby żądań.

Publiczny odczyt opublikowanych treści nie musi wymagać logowania. Operacje prywatne i zapis potrzebują natomiast sprawdzenia tożsamości oraz uprawnień do konkretnego zasobu. Cookie używane w kontekście WordPressa współpracuje z nonce REST; samo posiadanie sesji przeglądarki nie zastępuje poprawnej obsługi żądania. Szczegóły opisuje dokumentacja uwierzytelniania REST.

Hasła aplikacji nadają się do kontrolowanej komunikacji zewnętrznego systemu z WordPressem przez HTTPS. Konto powinno mieć tylko potrzebne uprawnienia, a sekret musi dać się odwołać. Nie umieszczaj wspólnego hasła integracyjnego w kodzie JavaScript wysyłanym do przeglądarki ani w aplikacji mobilnej rozdawanej użytkownikom. Taki klient nie zapewnia poufności wspólnego sekretu. Potrzebuje odpowiedniego modelu sesji użytkownika lub kontrolowanej warstwy serwerowej.

JWT i OAuth wymagają konkretnej implementacji, w tym obsługi wygaśnięcia i odwołania. Sam format JWT nie gwarantuje odświeżania tokenów. CORS reguluje zachowanie przeglądarki między pochodzeniami, ale nie jest autoryzacją API. Nie zastąpi kontroli uprawnień po stronie serwera. Własne endpointy również wymagają takiej kontroli; poprawne użycie hooków WordPressa to tylko część implementacji.

Komunikat o nieprawidłowym JSON może oznaczać, że klient dostał HTML strony błędu, przekierowanie do logowania lub komunikat zabezpieczenia. Zacznij od metody, adresu, statusu HTTP i treści odpowiedzi w narzędziach przeglądarki. Nie udostępniaj publicznie nagłówków autoryzacji ani danych klienta z przechwyconego żądania.

Rozróżnij błąd routingu, odmowę uprawnień, problem serwera i zmianę struktury danych. Dopiero wynik wskazuje, czy badać reguły adresów, sesję, firewall czy kod. Ponowny zapis permalinków nie jest uniwersalnym pierwszym krokiem. Konflikty wtyczek odtwarzaj na kopii, bez wyłączania całego zestawu na produkcji.

Przed wdrożeniem sprawdź poprawny odczyt, pusty wynik, brak uprawnień oraz zachowanie przy błędzie. Operacje zapisu testuj na izolowanych danych bez realnych wysyłek i płatności. Zapisz kontrakt oraz osobę odpowiedzialną za jego utrzymanie. Opisz planowaną integrację KC Mobile, wskazując systemy i potrzebne zasoby. Dalsze wsparcie może obejmować małe pakiety godzinowe; zakres i warunki SLA ustalamy indywidualnie.