PrestaShop Webservice API: Przewodnik po uwierzytelnianiu i integracji

Sklep PrestaShop rzadko pozostaje odizolowany na długo. Wcześniej czy później musi komunikować się z systemem ERP, platformą handlową, systemem magazynowym, platformą księgową lub aplikacją mobilną, a ruch ten przechodzi przez… API usługi internetowej PrestaShop, interfejs CRUD ujawniający jednostki sklepu przez HTTP. Uwierzytelnianie jest celowo proste: generujesz klucz dostępu w zapleczu i wysyłasz go jako nazwę użytkownika w nagłówku HTTP Basic Auth z pustym hasłem. Bez uzgadniania OAuth, bez odświeżania tokena i bez wygaśnięcia. Każde żądanie dziedziczy dokładnie te same uprawnienia, które zostały przyznane danemu kluczowi, dlatego klucz o nieodpowiednim zakresie jest najbardziej niebezpiecznym obiektem we wdrożeniu PrestaShop.

Integracje zazwyczaj zaczynają się od „tylko synchronizacji produktów”. Przeradzają się w prawdziwą pracę, gdy pojawiają się kombinacje, stany magazynowe, wiele języków, konteksty multistore i przepływ zamówień. Ten przewodnik omawia zakres dostępu, uwierzytelnianie, wybór punktów końcowych oraz błędy mapowania, które sprawiają, że technicznie poprawne wywołanie API daje nieprawidłowy wynik.

1.0 Czym jest API usługi internetowej PrestaShop i gdzie się kończy?

PrestaShop opiera się na założeniu, że pozwala sprzedawcom udostępniać narzędzia firm trzecich do bazy danych sklepu za pośrednictwem API CRUD. To uczciwy opis zarówno zasięgu, jak i ograniczeń. API to cienka, ogólna warstwa na encjach ObjectModel PrestaShop, a polecenia HTTP są odwzorowywane na operacje w bazie danych:

Metoda wykonania	Działanie
GET	Czytaj
POST	Stwórz
PUT	Aktualizacja (pełny obiekt)
ŁATA	Częściowa aktualizacja
DELETE	Usunięcia

Jest nie API oparte na logice biznesowej. Nie uruchamia ono procesu finalizacji zamówienia, nie pobiera płatności ani nie weryfikuje go w taki sposób, jak PaymentModule::validateOrder(), ale przenosi rekordy. To rozróżnienie wyjaśnia większość dziwnych zachowań zgłaszanych przez programistów i dlatego tworzenie zamówień bezpośrednio przez API jest znaną pułapką, a nie funkcją.

Katalogiem głównym jest /api/ w domenie sklepu. Polecenie GET /api/ zwraca wszystkie zasoby, do których może dotrzeć bieżący klucz, wraz z adnotacjami dotyczącymi metod, na które zezwala. Pomyślna odpowiedź informuje o czterech rzeczach naraz: usługa internetowa jest włączona, klucz został zaakceptowany, serwer WWW poprawnie routuje i klucz ma użyteczne uprawnienia. Rozpoczynaj każdą sesję debugowania w tym miejscu.

2.0 Jak włączyć usługę internetową PrestaShop i wygenerować klucz dostępu

Usługa internetowa wysyła niepełnosprawny. Nic nie działa, dopóki nie włączysz tego pod Parametry zaawansowane → Usługa internetowa w zapleczu. Na tej stronie znajduje się drugi przełącznik, który umożliwia akceptację klucza w adresie URL. Pozostaw go wyłączonym, chyba że przeczytałeś sekcję uwierzytelniania poniżej i nadal go potrzebujesz.

Następnie wygeneruj klucz zamiast go wymyślać i podaj opis, który nazwie system zużywający:

         
    Synchronizacja Marketplace nie jest kluczem API   
    Test złącza magazynowego ERP   
    Integracja aplikacji mobilnych   
    Przygotowanie - Raportowanie nowego klucza 2

Wygląda to na porządki. Ale nimi nie jest: gdy sprzedawca uruchamia pięć integracji i jeden klucz zaczyna powodować błędy, opis jest jedyną wskazówką, którą aplikację otworzyć.

Konfiguracja uwierzytelniania i dostępu do interfejsu API usługi internetowej PrestaShop

Siatka uprawnień to Twoja pierwsza granica bezpieczeństwa

Pod kluczem znajduje się macierz zasobów. Każdemu z ponad 80 zasobów można niezależnie przyznać funkcje GET, POST, PUT, PATCH, DELETE i HEAD. Ponieważ kluczem jest tylko poświadczenie, brak hasła, brak podpisu, brak wygaśnięcia, ta siatka is Twoja granica uwierzytelniania w API PrestaShop. Oficjalna dokumentacja zaleca ostrożność w przypadku uprawnień kluczy właśnie z tego powodu.

Integracja	Zasoby	Metody
Synchronizacja zapasów	stan zapasów	DOSTAĆ, POŁOŻYĆ
Katalog odczytany	produkty, kombinacje	GET
Łącznik Marketplace	produkty, obrazy, stan magazynowy	GET, POST, PUT
Raportowanie zamówień	zamówienia, szczegóły_zamówienia, stany_zamówienia	GET

Nie włączaj wszystkiego, ponieważ integracja „może tego później potrzebować”. Narzędzie do raportowania nie ma możliwości modyfikowania zamówień; usługa magazynowa nie ma możliwości odczytywania adresów klientów. Zacznij od najmniejszego zestawu, który działa, i rozszerzaj go o dowody, co dodatkowo ułatwia diagnozę, ponieważ GET /api/products zakończony powodzeniem, a PUT /api/products/123 zakończony niepowodzeniem, wskazuje bezpośrednio na macierz, a nie na Twój kod.

Dwa kolejne nawyki: jeden klucz na integrację, nigdy jeden współdzielony przez cztery systemy i brak polecenia DELETE, chyba że wymaga tego przepływ pracy. W przypadku produktów, preferując active=0, usunięty produkt zabiera ze sobą swoją historię.

Jak uwierzytelniać żądania API usługi internetowej PrestaShop

Podstawowa autoryzacja, wpisz nazwę użytkownika, puste hasło:

curl -u "TWÓJ_KLUCZ_DOSTĘPU:" https://example.com/api/products

Dwukropek na końcu to puste hasło. Pomiń go, a curl będzie czekać na dane wejściowe, co jest częstym pierwszym problemem. Ręczne tworzenie nagłówka:

$apiKey = getenv('PRESTASHOP_API_KEY');

$headers = ['Autoryzacja: Podstawowa ' . base64_encode($apiKey . ':')];

Odczytaj klucz ze środowiska, a nie dosłownie, i rotuj wszystko, co kiedykolwiek miało kontakt z repozytorium. Klucze nie wygasają same z siebie, więc rotacja to kwestia umiejętności, inaczej nic się nie stanie.

PrestaShop akceptuje również https://[email chroniony]/api/. W porządku dla trzydziestosekundowego sprawdzania przeglądarki, ale nie dla środowiska produkcyjnego, ponieważ adresy URL trafiają do historii, logów proxy, monitorowania i zrzutów ekranu; dokumentacja zaleca zamiast tego nagłówek Authorization. Uruchom wszystko przez HTTPS, uwierzytelnianie podstawowe to base64, a nie szyfrowanie.

Warto poznać jeden problem środowiskowy, zanim się z nim zetkniesz: klucz działa w adresie URL, identyczny klucz zwraca błąd 401 w nagłówku, a oczywistym wnioskiem jest to, że klucz jest błędny. Często tak nie jest, niektóre konfiguracje Apache/CGI w ogóle nie przekazują nagłówka autoryzacji do PHP. Udokumentowane poprawki:

CGIPassAuth włączony

lub w przypadku starszych wersji Apache:

SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1

Jeśli klucz działa w jednej metodzie uwierzytelniania, ale nie w innej, przed wygenerowaniem kluczy po raz czwarty sprawdź serwer WWW.

2.1 Błędy API PrestaShop: Dlaczego Twoje żądanie zwraca kod 401, 403 lub 404

Potraktuj kod statusu jako wskazówkę dotyczącą która warstwa nie powiodło się i przestań przepisywać kod, dopóki się nie dowiesz.

401 Nieautoryzowane, tożsamość odrzucona. Kolejność: czy przełącznik usługi sieciowej jest włączony; czy wiersz klucza jest aktywny; czy skopiowano spację końcową; czy nagłówek autoryzacji dociera do PHP; czy wysyłasz klucz jako parametr zapytania zamiast uwierzytelniania podstawowego. API nie odczytuje parametru ?key=, a ten błąd jest częstszy niż powinien.

Zakazane 403Klucz prawidłowy, brak uprawnień. Komunikat głosowy: GET /api/ kończy się powodzeniem, podczas gdy jedno konkretne wywołanie zostało odrzucone.

404 Not Found W przypadku zasobu, o którym wiesz, że istnieje, zwykle oznacza to, że /api/ nie jest kierowane. Przetestuj dyspozytora bezpośrednio:

https://example.com/webservice/dispatcher.php?url=products

Jeśli zwraca dane, a /api/products nie, problem leży w konfiguracji serwera WWW, a nie w PrestaShop. Najczęściej pojawia się to po migracji hostingu, gdzie sklep działa idealnie, a jedynie API przestaje routować.

3.0 XML domyślnie, JSON na żądanie

Usługa sieciowa bazuje na XML. Nawiasy kątowe w miejscu, gdzie spodziewałeś się obiektu, oznaczają, że nic nie jest zepsute, po prostu nie zapytałeś:

curl -u "KLUCZ:" "https://example.com/api/products?output_format=JSON"

Nagłówki również działają (Output-Format: JSON, Io-Format: JSON); io_format ustawia dane wejściowe i wyjściowe, output_format ustawia tylko odpowiedź.

Następnie ograniczenie, które kształtuje architekturę łącznika: dokumentacja PrestaShop 8 stwierdza, że od wersji 8.1 usługa internetowa wyprowadza JSON, ale nie może odczytać danych wejściowych JSON. Zapisuje XML, więc typowy konektor wewnętrznie pobiera JSON i kompiluje XML dla każdego POST, PUT i PATCH. Zaplanuj asymetrię i ponownie sprawdź ją w dokumentacji deweloperskiej dla docelowej wersji.

Nie zgaduj tego XML-a, zapytaj w sklepie:

GET /api/products?schema=blank zwraca pusty szkielet gotowy do wypełnienia.
GET /api/products?schema=synopsis dodaje typy pól, wymagane flagi, walidatory i maksymalne rozmiary.

Streszczenie przewyższa wszelką dokumentację, w tym ten artykuł, ponieważ odzwierciedla że instalacja z jego Moduły i dodane do nich pola są znacznie bezpieczniejsze niż zakładanie, że kod XML produktu jest zgodny z danymi poprzedniego klienta. Formatowanie również jest rygorystyczne: 42 , nigdy z nowymi liniami i wcięciami wewnątrz znacznika wartości.

4.0 Podstawowe punkty końcowe i do czego właściwie służą

Istnieje ponad osiemdziesiąt zasobów. Integracje skupiają się wokół kilku.

4.1 Katalog i dlaczego produkt nie jest kombinacją

Produkty, kategorie, kombinacje, producenci, obrazy. To właśnie tutaj tkwi większość złożoności zapisu i gdzie pojawia się najkosztowniejszy błąd mapowania.

Koszulka to jeden produkt z jednym identyfikatorem. Jej warianty w rozmiarach: małym, średnim i dużym to kombinacje, każda z własnym identyfikatorem i własnym rekordem magazynowym. Utwórz je w kolejności: opcja produktu (grupa atrybutów „Rozmiar”), następnie wartość opcji (S, M, L), a następnie kombinacja łącząca wartości z produktem. Pole ceny w kombinacji to wpływ na cenę dodawana do ceny bazowej, a nie końcowej.

Teraz tryb awaryjny. Integracja aktualizuje stan magazynowy produktu 500, gdy ilość możliwa do sprzedaży należy do kombinacji 502. API zwraca 200, log informuje o powodzeniu, a witryna sklepowa pokazuje błędną dostępność. Nic nie uległo awarii poza mapowaniem, dlatego praca nad inwentaryzacją i rynkiem wymaga czegoś więcej niż tylko wiedzy o punktach końcowych.

Obrazy stanowią oddzielny proces, przesyłany w częściach do /api/images/products/{id}, a nie osadzony w danych produktu. W przypadku katalogu obejmującego tysiące obiektów, ponowne przetwarzanie każdego obrazu przy każdym uruchomieniu jest zazwyczaj najwolniejszą czynnością wykonywaną przez integrację. Przechowuj mapowania i zmieniaj obrazy tylko wtedy, gdy coś się zmieni.

4.2 Mały punkt końcowy, duże konsekwencje

stock_availables to często zasób o najwyższej częstotliwości w systemie i najprostszy do wywołania: odczyt, zmiana ilości, zapis zwrotny. Problemem jest uzgadnianie: platforma sprzedaje jedną jednostkę, jej liczba spada do 9, PrestaShop nadal wskazuje 10 i coś musi wypełnić tę lukę. Zaprojektuj pętlę w następujący sposób: stan odczytu → określenie delty → zapis → potwierdzenie → logowanie, zamiast wpisywać wartości bezwzględne co kilka minut i czekać.

4.3 Zamówienia maszyny stanowej, a nie tabeli

zamówienia, szczegóły_zamówienia, historie_zamówień, stany_zamówień. Większość integracji wymaga dużego odczytu: ściąganie zamówień, ściąganie pozycji zamówienia, wysyłanie zmian statusu.

Status to część z idiomem. Nie DODAJ nowego stanu do zamówienia, utwórz rekord order_histories, który steruje maszyną stanów i powiadomieniami dla klientów. W zależności od konfiguracji, przejście może dotyczyć fakturowania, wiadomości e-mail, stanu wysyłki i stanu magazynowego, a identyfikatory stanów różnią się między sklepami, dlatego należy wykonać zapytanie o order_states i mapować je według nazwy, zamiast wpisywać numer z etapu przygotowawczego.

Jeśli system zewnętrzny musi Stwórz Zamówienia, kierują je przez koszyk i kontroler modułu wywołujący rzeczywistą ścieżkę tworzenia zamówienia. Punkt końcowy CRUD omija logikę walidacji, stanu magazynowego i płatności, która sprawia, że zamówienie jest wiarygodne.

4.4 Klienci, dane referencyjne i kontekst

Klienci, adresy i grupy to proste rekordy obarczone największymi obowiązkami w zakresie ochrony danych, dlatego należy je przyznawać tylko kluczom, które ewidentnie ich potrzebują. Zasoby referencyjne (operatorzy, kraje, waluty, języki, podatki, strefy, sklepy) mają niewielką objętość i dużą wartość: należy je pobrać raz przy uruchomieniu i zapisać w pamięci podręcznej, ponieważ niemal każdy zapis wymaga identyfikatora z tej grupy.

Dwa wymiary kontekstowe wychwytują całkowanie. Pola wielojęzyczne nie są zwykłymi ciągami znaków, nazwa produktu jest oparta na identyfikatorze języka, więc Twoja warstwa musi zdecydować, o jakim języku i jaki jest język zapasowy, zanim zewnętrzna platforma zażąda jednej wartości. Multisklep Oznacza to, że jeden identyfikator produktu może oznaczać różne rekordy biznesowe dla każdego sklepu; usługa internetowa udostępnia w tym celu identyfikatory id_shop i id_group_shop, a stan magazynowy wymaga jednego lub drugiego, w zależności od strategii współdzielenia zapasów w sklepie. Błąd synchronizacji, który wygląda na losowy, zazwyczaj rozwiązuje się w momencie pojawienia się w logu kontekstu sklepu i języka.

5.0 Filtrowanie, stronicowanie i synchronizacja przyrostowa

Pobieranie całego katalogu za każdym razem to najszybszy sposób, aby sprzedawca odmówił integracji. Parametry, które ją blokują:

display=[id,reference,price,date_upd] zwraca tylko pola nazwane. display=full zwraca wszystko i stanowi rzeczywiste ryzyko wydajności na dużą skalę.
filter[reference]=ABC-123 pasuje dokładnie; składnia obsługuje również LIKE, OR, negację i porównania interwałowe.
sort=[date_upd_DESC] zamawia wyniki.
limit=50 bierze pierwsze pięćdziesiąt; limit=50,50 bierze wiersze 51–100 jako przesunięcie plus liczbę.
data=1 musi być ustawiona przed zastosowaniem filtrów zakresu dat, pominięcie jej spowoduje, że filtr zostanie zignorowany, zwrócone zostaną wszystkie dane, a błąd będzie traktowany gdzie indziej.

Gdy klient zgłasza, że „synchronizacja API jest zbyt wolna”, logi zazwyczaj pokazują, że integracja pobiera produkty, kombinacje, obrazy, kategorie i producentów dla każdego rekordu przy każdym uruchomieniu. Nic nie jest zepsute; architektura wykonuje niepotrzebną pracę. Sięgnij po filtrowanie, paginację, buforowane dane referencyjne i zapisany znacznik czasu ostatniej synchronizacji przed osiągnięciem maksymalnego czasu wykonania (max_execution_time).

6.0 Kiedy usługa internetowa nie jest odpowiednią warstwą

Usługa internetowa jest odpowiednia dla systemów, które potrzebują dość bezpośredniego dostępu do rekordów PrestaShop: ERP do produktów, magazyn do stanu magazynowego, raportowanie do zamówień. Znacznie gorzej sprawdza się w przypadku operacji biznesowych, takich jak logowanie, koszyk, finalizacja zamówienia, spersonalizowany ekran główny aplikacji. Te elementy wymagają logiki, a nie CRUD. Dlatego dodaj warstwę pośrednią:

Klient zewnętrzny → Warstwa integracyjna → Usługa internetowa PrestaShop → Baza danych

Ta warstwa odpowiada za uwierzytelnianie, reguły biznesowe, mapowanie, walidację, buforowanie i kształtowanie odpowiedzi. Klient mobilny pyta następnie o to, czego potrzebuje i otrzymuje przewidywalny obiekt, nie wiedząc, jak PrestaShop dzieli produkt na produkty, kombinacje, dostępność, cenę, język i obraz:

{ "product_id": 123, "name": "Buty do biegania", "price": 79.99, "available": true }

Ta granica pozwala jednemu backendowi obsługiwać stronę internetową, aplikację, platformę handlową i system ERP bez przenikania się czterech zestawów założeń. To architektura stojąca za produktami stworzonymi specjalnie w tym obszarze. Na przykład kreator aplikacji mobilnych PrestaShop firmy Knowband utrzymuje sklep jako źródło prawdy i synchronizuje katalog, zamówienia i wielojęzyczne treści z natywnymi klientami Androida i iOS, zamiast udostępniać surowe zasoby urządzeniu.

Praca na rynku niesie ze sobą tę samą lekcję, ale z dodatkowym atutem: drugiej W grę wchodzą API PrestaShop i Marketplace, które mogą ulec zmianie bez ostrzeżenia. Konektor musi zapewnić stabilność mapowania kategorii, mapowania atrybutów, stanu ofert, importu zamówień i przepływu zwrotnego statusu w obu platformach. Integracja PrestaShop eBay Marketplace firmy Knowband obejmuje te obszary dla eBay, ofert, stanu magazynowego i zamówień, co warto rozważyć przed samodzielnym stworzeniem rozwiązania. Uczciwe porównanie nie polega na porównaniu kosztów licencji z kosztami rozwoju, ale na porównaniu kosztów licencji z kosztami rozwoju. plus każda kolejna wersja będzie udoskonalona na obu platformach.

7.0 Testowanie dostępu przed zbudowaniem czegokolwiek

Piętnaście minut tutaj oszczędza dni. Uruchomienie tego w sklepie docelowym z kluczem produkcyjnym faktycznie wykorzysta:
GET /api/ zwraca 200 i listę zasobów. Jeśli nie, przerwij, nic, co dzieje się dalej, nie ma jeszcze znaczenia.
Ta lista zawiera wszystkie potrzebne zasoby wraz z metodami. Luki to problemy z siatką uprawnień, a nie błędy w kodzie.
GET /api/products?limit=1 zwraca rekord, potwierdza routing i dostęp do odczytu.
To samo wywołanie z &output_format=JSON zwraca JSON.
GET /api/products?schema=synopsis daje Ci specyfikację pola dla to sklep. Przeczytaj to przed napisaniem programu do tworzenia ładunków.
GET /api/products?filter[id]=[123], sprawdź, czy filtrowanie działa zgodnie z oczekiwaniami.
Jeden kontrolowany zapis na etapie przygotowawczym, zweryfikowany poprzez ponowne odczytanie, 200 nie jest dowodem, że pole wylądowało zgodnie z planem.
Celowe błędy: nieprawidłowy klucz, ograniczone zasoby, błędny identyfikator, nieprawidłowo sformatowany ładunek. Twój klient powinien przewidywalnie wyświetlać błędy, zamiast je łykać.
Konkretnie chodzi o ścieżkę nagłówka autoryzacji, a nie skrót klucza w adresie URL.

Postman lub Insomnia ułatwiają to zadanie, a w dokumentacji deweloperskiej znajduje się samouczek testowania oparty na Postmanie. Dla użytkowników PHP, prestashop/prestashop-webservice-lib obsługuje szablon cURL i XML i pozostaje standardowym klientem.

8.0 PrestaShop 9: Usługa internetowa obok interfejsu API administratora

PrestaShop 9 zawiera zarówno starszą usługę internetową, jak i nowszą Interfejs API administratora, a są to różne systemy, które współistnieją w jednej instalacji. Dokumentacja deweloperska opisuje API administracyjne jako oparte na OAuth, zbudowane na platformie API z projektem CQRS i punktami końcowymi, które są bardziej zorientowane na domenę niż zasoby modelu obiektowego usługi sieciowej. Uwierzytelnianie odbywa się za pomocą tokenów dostępu OAuth2, a nie klucza dostępu w uwierzytelnianiu podstawowym, a nawet parametry multishop różnią się — shopId, shopGroupId, shopIds, allShops zamiast id_shop i id_group_shop.

Wszystko powyżej opisuje usługę internetową, której zachowanie jest konsekwentnie kontynuowane w wersjach 1.7, 8.x i 9.x: model uwierzytelniania podstawowego z kluczem i kluczem, katalog główny /api/, dane wyjściowe XML-first oraz siatka uprawnień. Integracje z wersji 1.6 nadal działają, choć zestawy pól zmieniały się wraz z każdą główną wersją. Po aktualizacji należy ponownie generować migawki schematu, zamiast ufać starszemu mapowaniu.

W przypadku nowej kompilacji, przed domyślnym wyborem którejkolwiek z nich, sprawdź dokumentację interfejsu API administratora, aby poznać potrzebne zasoby. W przypadku istniejącego łącznika, traktuj migrację jako osobny projekt: nie są one natychmiastowymi zamiennikami i nie są tak przedstawiane w dokumentach deweloperskich.

9.0 Błędy, które kosztują najwięcej czasu

Usługa internetowa nigdy nie została włączona. Naprawa jest łatwa i zajmuje wiele godzin, ponieważ objawia się jako problem z uwierzytelnianiem.
Zakodowane na stałe identyfikatory dla języków, walut lub stanów zamówień, skopiowanych ze sklepu deweloperskiego do klienta, którego identyfikatory się różnią. Zapytaj i zmapuj je.
PUT z częściowym ładunkiem. Pełna aktualizacja wymaga całego obiektu; należy użyć PATCH dla kilku pól.
Odczytanie protokołu HTTP 200 jako sukces w biznesie. Oznacza to, że prośba została przetworzona, a nie że wydarzyło się to, co trzeba.
Brak strategii ponawiania prób. Utracona odpowiedź po pomyślnym zapisie oznacza, że ponowna próba musi być idempotentna, w przeciwnym razie powstaną duplikaty.
Brak dzienników synchronizacji. Rejestruj znacznik czasu, punkt końcowy, metodę, identyfikator zasobu i sklepu, status, liczbę ponownych prób i identyfikator synchronizacji – nigdy klucz, dane uwierzytelniające ani dane osobowe. Po trzech dniach ten log będzie Twoim jedynym dowodem.
Status binarny: sukces/niepowodzenie. „Brak synchronizacji” może oznaczać, że żądanie nigdy nie zostało wysłane, zwróciło błąd 401, zwróciło błąd 200, ale mapowanie nie powiodło się lub utworzyło produkt, ale przesłanie obrazu nie powiodło się. Ujawnij scenę, a nie tylko werdykt.

Gdy coś się zepsuje, postępuj zgodnie z żądaniem, zamiast edytować kod: czy opuściło aplikację, dotarło do PrestaShop, przeszło uwierzytelnienie, przeszło uprawnienia, zwróciło oczekiwany zasób, poprawnie przeanalizowało, poprawnie zmapowało, zakończyło operację biznesową i zostało zalogowane? Sprawdzenie każdej granicy niezależnie jest lepsze od zgadywania, zwłaszcza w przypadku klienta mobilnego, niestandardowej warstwy, PrestaShop i sklepu na ścieżce.

10.0 Dokąd się stąd udać

API usług internetowych PrestaShop ceni precyzję bardziej niż spryt. Włącz je celowo, określ zakres jednego klucza dla każdego użytkownika poprzez siatkę uprawnień, uwierzytelnij się przez HTTPS z prawdziwym nagłówkiem autoryzacji i odczytaj własny schemat=synopsis sklepu przed napisaniem generatora danych. Wykonaj te cztery czynności, a reszta to już zwykła manipulacja HTTP.

Następnie buduj w tej kolejności: uwierzytelnianie, GET /api/, odczyt jednego produktu, jego kombinacji, jego stanu magazynowego, wykonanie kontrolowanego zapisu, dodanie filtrowania i stronicowania, a dopiero potem synchronizacja, ponowne próby i logowanie. Udowodnij połączenie, udowodnij mapowanie, udowodnij synchronizację, a następnie skaluj. Nie zaczynaj od 50 000 produktów.

Pytanie, które decyduje o tym, czy integracja przetrwa produkcję, nie brzmi: „do którego punktu końcowego mam się zwrócić?”, ale: „jakie dane przenoszę, kto jest ich właścicielem, co się stanie, gdy żądanie się nie powiedzie, i skąd będę mieć pewność, że oba systemy są nadal spójne?”.

Jeśli masz pytania lub potrzebujesz pomocy w zakresie wydajności lub migracji witryny, nasi eksperci są do Twojej dyspozycji. Skontaktuj się z zespołem Knowband pod adresem [email chroniony] już dziś skorzystaj z niezawodnych wtyczek eCommerce dostosowanych do Twoich potrzeb.