Wrzasq.pl

Allegro WebAPI tutorial vol. 6

Sunday, 26 July 2009, 00:50

Część I
Część II
Część III
Część IV

Odsłona szósta już

Po dość długim czasie ponownie miałem styczność z Allegro WebAPI - ponownie z naciskiem na tworzenie aukcji (sprzedaż). Zauważyłem, że w poprzednich częściach umknęło mi kilka rzeczy dlatego postanowiłem nadrobić teraz zaległości i wspomnieć o kilku rzeczach. Jak również zauważyliście ostatnio nie pisałem zbytnio na ten temat, a również i ta część nie będzie zbyt obszerna. Po pierwsze jest to spowodowane brakiem czasu, a po drugie wszystkie podstawowe elementy usługi już omówiłem, tak więc raczej nie spodziewajcie się w przyszłości kolejnych odsłon na większą skalę, no chyba, że znajdzie się dość obszerny materiał do przedstawienia. Na pocieszenie powiem, że Allegro ogłosiło konkurs na tutorial do Allegro WebAPI, więc może będzie więcej ciekawych materiałów (co nie zmienia faktu, że jest to kpina z użytkowników, aby swój psi obowiązek dokumentowania zwalać na użytkowników i to w tak perfidny sposób na dodatek jako marchewkę dając bilet na koncert :|).

Na początek powiem, że serwis testowy nie jest niestety uaktualniany (przynajmniej nie są wprowadzane takie zmiany, aby mechanizm był adekwatny) i tak na przykład na serwisie testwebapi.pl nie przetestujemy nowych sposobów ustawiania kosztów przesyłki. Tak więc trzeba pamiętać, że nawet jeśli skrypty z poprzednich części mojego tutoriala będą działać na serwisie testowym, należy dokładnie je przeanalizować pod kątem serwisu głównego, gdyż tam mogą wystąpić rozbieżności.

doVerifyItem()

Natomiast główne dwie rzeczy, o których mam zamiar napisać, to zachowywanie się metody doVerifyItem(). Po pierwsze, tak jak to widać w kodzie z poprzedniej części metoda ta (szczególnie w przypadku PHP) zwraca po prostu wartość liczbową. Nie wiem, czy jest to standardowe zachowanie bibliotek SOAP, czy może specyfika tej z PHP, ale w przypadku, gdy funkcja zwraca tylko jeden argument, nie ważne, że nazwany jako pole listy, to jest on zwracany bezpośrednio. Nie należy zatem odwoływać się do pola item-id:

$check = $client->doVerifyItem($session['session-handle-part'], $local);

// ŹLE!
//if($item['item-id'] == $check['item-id']) {}

// dobrze
if($item['item-id'] == $check) {}

Drugą sprawą jest to, iż Allegro WebAPI na prawdę zapamiętuje nasz lokalny identyfikator i nawet jeśli doNewAuctionExt() utworzy nową aukcję, o nowym identyfikatorze, doVerifyItem() zwróci nam identyfikator pierwszej aukcji utworzonej dla naszego identyfikatora lokalnego. Wydawać by się mogło, że używanie ID produktu z naszego sklepu jest dobrym wyjściem, ale tak nie jest - gdy wystawimy po raz drugi ten sam produkt (co przecież jest powszechnie używane), wartości identyfikatora aukcji, oraz tego, który otrzymamy po weryfikacji będą się różnić:

// $form za każdym razem jest listą pól, jej ustawianie z oczywistych względów pomijam
// niech $productID1 i $productID2 to ID produktów z naszej bazy

// pierwsz aukcja - zadziała
$item1 = $client->doNewAuctionExt($session['session-handle-part'], $form, 0, $productID1);
$check1 = $client->doVerifyItem($session['session-handle-part'], $productID1);

// druga aukcja - to pierwsza aukcja drugiego przedmiotu, czyli zadziała
$item2 = $client->doNewAuctionExt($session['session-handle-part'], $form, 0, $productID2);
$check2 = $client->doVerifyItem($session['session-handle-part'], $productID2);

// i tutaj już jest problem
$item3 = $client->doNewAuctionExt($session['session-handle-part'], $form, 0, $productID1);
$check3 = $client->doVerifyItem($session['session-handle-part'], $productID1);

if($item3['item-id'] == $check3) // FAŁSZ!
{
}

if($item1['item-id'] == $check3) // PRAWDA
{
}

Identyfikator lokalny aukcji, musi być unikalny - dobrym pomysłem może być na przykład stworzenie nowej tabeli z aukcjami Allegro. W kwestii Allegro WebAPI to na razie wszystko, może jeszcze kiedyś coś mi się przypomni ciekawego ;).

Tags: , , , , ,