Allegro WebAPI jest bodaj najbardziej rozbudowanym i najlepiej udokumentowanym API spośród polskich serwisów aukcyjnych. Allegro jest wiodącym serwisem aukcyjnym w Polsce, z największą liczbą sprzedających, kupujących oraz aplikacji ułatwiających integrację z serwisem.
Podczas implementowania klienta Allegro natrafiłem na kilka mniej lub bardziej istotnych problemów. Poniżej przedstawię kluczowe dolegliwości Allegro API i serwisu testowego, które moim zdaniem powinny zostać wyeliminowane w nowszych wersjach.
Allegro WebAPI
-
niespójność argumentów
raz podaje się
country-code
,country-id
, czasem zamiast myślnika używany jest podkreślnik, a w nowszych metodach zamiastwebapi-key
icountry-code
uzywany jestsession-handle
. -
niespójność odpowiedzi
niektóre metody zwracają listy, a niektóre słowniki - czasem odwoływać można się przez klucz, a czasem trzeba przez index (najlepiej zamapować indeksy na klucze, co zrobiłem w moim kliencie Allegro)
-
nazwy kluczy
-
prefiksowanie wszystkich kluczy nie ma sensu
wydłuża kod, jest bardziej błędogenne (prawdopodobieństwo literówek jest większe)
-
myślniki użyte w kluczach to fatalny pomysł
zwykle do właściwości obiektów SOAP`a można dostać się przez... właściwości obiektu; w przypadku Allegro odwoływać można się tylko przez klucz (nie można używać myślnika w nazwach properties)
-
-
wersjonowanie
API Allegro jest wersjonowane, ale w danym czasie mamy dostęp tylko do najnowszej wersji. Aplikacje klienckie przestają działać prawidłowo, jeśli w API zostanie zerwana kompatybilność wstecz. A to zdarza się dość często. Niestety o takiej krytycznej zmianie świadczy często skala lamentów na forum Allegro WebAPI. Trzeba (niestety) śledzić komunikaty.
Takie podejście uniemożliwia napisanie działającej aplikacji klienckiej. Co najwyżej można ustrzec się przed padem za pomocą odmowy wykonania operacji i komunikatu w stylu "API Allegro zostało zaktualizowane. Skontaktuj się ze sprzedawcą".
Brak dostępu do różnych wersji API uważam to za największą wadę Allegro.
Kluczowe zmiany, zrywające BC, powinny być wprowadzane tylko w wersjach, których pierwszy (najważniejszy) numer ulega zmianie. Pozostałe numery wersji powinny odpowiadać odpowiednio za minor features oraz bugfixes. Kilka głównych gałęzi API powinno być stale dostępnych.
Nowe wersje również powinny być udostępniane programistom, aby mogli przygotować klienty pod nowe API. Jednocześnie byliby betatesterami.
-
skomplikowane struktury dancych
Niektóre metody API przyjmują zadziwiające struktury danych, aby zrealizować jakieś zadanie. Niech za przykład posłuży metoda
doNewAuctionExt
i sposób przekazania danych za pomocąfields
.
Środowisko testowe (testwebapi.pl)
-
Niedostępne opcje
Niektóre funkcjonalności nie są dostępne w środowisku testowym, np. Płacę z Allegro (PzA). Rozumiem, że PzA jest oddzielnym podsystemem i nie ma trybu testowego.
-
Puste wyniki
Niektóre funkcje API w trybie testowym nie zwracają danych. Nie da się w pełni przetestować aplikacji klienckiej.
-
Błędy interfejsu
Formularze, które po zwalidowaniu gubią dane doprowadzają do powstawania nerwowych drgawek. Stąd wnioskuję, że oprogramowanie testowe jest zupełnie inne niż wersja produkcyjna (tam nie występują podobne błędy).
-
Urywający się PHP
Często po edycji aukcji lub wystawiania na nowo nie ma przycisku "List an item". Nie ma też stopki. Skrypt PHP urywa się gdzieś w połowie. Wystawienie nowej aukcji rozwiązuje problem, ale wydłuża czas testowania.
Podsumowanie
Czy kiedyś powyższe problemy będą rozwiązane? Liczę na to. A póki co koszty implementacji i utrzymania oprogramowania opartego na API Allegro idą górę.
Mimo wyżej wymienionych wad Allegro WebAPI jest dość porządne, szczególnie ze względu na:
- ilość dostępnych funkcji,
- dość dobrą i pełną dokumentację,
- stały support ze strony Allegro na forum,
- komunikaty o zmianach zrywających kompatybilność (lepsze to niż nic, choć nie rozwiązuje problemu wersjonowania).
API jednego z serwisów aukcyjnych na Węgrzech wypada przy Allegro bardzo słabo.