search

allegro / allegro-api

Issue tracker and wiki for Allegro REST API
https://developer.allegro.pl/
217 stars 39 forks source link

[NEWS] Wygaszamy WebAPI do obsługi ofert i sprzedaży #1597

Open MartaNowaczyk opened 5 years ago

MartaNowaczyk commented 5 years ago

Przypominamy, że zgodnie z zapowiedzią 3 czerwca 2019 usuniemy metody do obsługi i zarządzania ofertami:

Przejdź na zasoby w REST API Allegro, które pozwolą ci wystawiać i zarządzać ofertami - więcej informacji znajdziesz w tym poradniku.

lkowol commented 5 years ago

Proszę o informację, czy wspomniany termin jest terminem ostatecznym i nieprzesuwalnym. W mojej opinii, wycofywanie kluczowych metod w momencie, w którym spora część nowego REST API jest nadal w wersji beta, jest zbyt pochopne.

Zdaję sobie sprawę, że wycofywane metody są już zastąpione docelowymi, niebędącymi w wersji beta. Zakładam jednak, że w większości przypadków wdrażanie nowej integracji nie opiera się na zastępowaniu metod podobnymi i modyfikowaniu integracji żeby jakoś działała, a na przygotowaniu nowego, w pełni funkcjonalnego i działającego systemu, którym można zastąpić integrację z WebAPI.

Zaproponowana forma (wygaszanie API) wymusza jeden z dwóch scenariuszy:

Scenariusze te są o tyle problematyczne, ze rozbieżność dotyczy funkcjonalności najbardziej istotnej - obsługi zamówień.

Zakładam, że zależy Państwu, aby przejście na nowe API przeszło sprawnie. Obecna forma to utrudnia, jeśli nie całkowicie wyklucza.

Sugerowałbym przedłużenie terminu do czasu np. miesiąca od ustabilizowania wszystkich metod API niezbędnych dla procesu składania i obsługi zamówienia.

MartaNowaczyk commented 5 years ago

Termin jest w tym momencie aktualny. Dziękujemy za sugestię. Jest to miejsce w którym możecie dodawać swoje argumenty za i przeciw. Na pewno wszystkim się przyjrzymy.

lkowol commented 5 years ago

Dziękuję za odpowiedź. Skoro termin jest aktualny "w tym momencie", znaczy to, że istnieje prawdopodobieństwo jego przesunięcia.

Myślę, że i Państwu, i Państwa klientom zależy, żeby wszystko działało sprawnie. Przeglądając komentarze z pozostałych tematów, ciężko natrafić na jakiekolwiek "za" ze strony klientów, a najbardziej merytoryczny argument płynący ze strony Allegro to argument p. Pawła Taberskiego: "Ponadto obecnie na bieżąco musimy utrzymywać oba te środowiska, przejście w pełni choć z kilkoma głównymi funkcjonalnościami pozwoli nam mocniej się skupić nad wdrażaniem kolejnych zasobów w REST API i przyspieszy ten proces.".

Chciałbym jednak zauważyć, że jest to argument bardzo egoistyczny, ponieważ odciążając Was od utrzymywania dwóch integracji zmusza się do tego klientów (co opisałem w komentarzu powyższym).

Myślę, że lepszą opcją będzie nie rozwijanie obu środowisk jednocześnie, a dokończenie REST API tak, aby kluczowe metody nie były w wersji beta.

Sugerowałbym również nie "przyjrzenie się" argumentom, a merytoryczną dyskusję i ustosunkowywanie się do nich, a także publikowanie własnych "za".

Rozumiałbym wygaszanie API w momencie, w którym byłaby to stopniowa motywacja na zmianę integracji na kompletną, działającą i przetestowaną alternatywę. W obecnym momencie zmusza się nas do przechodzenia w częściach, co nie jest dobrą praktyką - jest też to w moim prywatnym odczuciu nieprofesjonalne, szczególnie w związku z argumentacją pana Pawła, pt. "Wyłączamy, żeby nam było łatwiej".

barthoos commented 5 years ago

Ja szczerze powiedziawszy nie dopuszczam do siebie mysli, ze wylaczycie WebAPI 3go czerwca. Juz teraz wiem, ze nie wyrobie sie przesiadka na 100% i blisko 2000x uzytkownikow mojej aplikacji zawiesi swoja dzialalnosc na Allegro do czasu az sie z tym wyrobie.

Osobiscie migracja u mnie wygladala/wyglada tak:

Onixarts commented 5 years ago

Projektowanie od zera to byłby i tak pikuś. U nas podobnie, całą obsługę Allegro w zasadzie piszemy od nowa, bo zmieniło się tak wiele rzeczy, że nie da się pogodzić starego z nowym. Dużym problemem jest to, że trzeba w miarę bezboleśnie zapewnić przejście użytkowników ze starej wersji na nową (mowa o aplikacji desktopowej). Gdyby chodziło tylko o napisanie integracji od nowa to sprawa wydaje się w miarę prosta. Niestety w rozbudowanych systemach jest tak wiele różnych powiązań i zależności, które narosły przez lata, że wyplewienie starego API i zastąpienie go niekompatybilnym nowym, nastręcza dodatkowych trudności i problemów, które trzeba rozwiązać. Na oko, obsługa nowego API to około 30-40% wszystkich zmian potrzebnych w aplikacji, aby dokonać migracji API.

barthoos commented 5 years ago

Ja najbardziej problematycznym znajduje (chociaz jeszcze do tego nie doszedlem) obsluge bledow w dzialaniu ciaglym. 8 lat doswiadczen z WebAPI nauczyly mnie, ze nieprzewidzianych sytuacji jest tak wiele, ze bez odpowiedniej ich obslugi na poziomie exceptionow potrafi to skutecznie namieszac. Od wystawienia w kolku kilkuset razy tej samej aukcji, przez uporczywe nieprawdziwe info ze strony API ze aukcja nie istenieje a uzytkownik ma zle haslo, po zmiany cen na zlotowke przy towarach wartych kilka ladnych tysiecy :) I nie mowie tutaj tylko o sytuacjach zaleznych od Allegrowego API, ale samej logice w mojej aplikacji. A takie rzeczy tylko z czasem. Musze miec skale (kilku "sytych" uzytkownikow testujacych) i czas (mialem bledy ktore pojawialy sie przy scisle okreslonych sytuacjach i nie wystapily przez kilka lat nawet).

neldh commented 5 years ago

Ze swojej strony dodam, że dla systemów, które cały czas muszą chodzić i zbierać zamówienia z waszego systemu, taki stan rzeczy wygląda na mocno nieprofesjonalny. Brakuje sensownej metodyki mapowania id różnych rzeczy między WEBAPI a RESTAPI, tam gdzie to id się zmienia. Taka rzecz jest po prostu nie do zaakceptowania. Wszystkie mapowania powinny być dostępne ZANIM zaczęliście wyłączać cokolwiek w WEBAPI. Ich brak mocno wydłuża proces przechodzenia na RESTAPI, bo istnieje konieczność własnoręcznego kombinowania i wymyślania rozwiązań na własną rękę po naszej stronie. Rozwiązań, które profesjonaliści zapewniliby nam na START.

pietrach commented 5 years ago

Jeszcze jedna rzecz, którą pasowałoby dodać bo nie do końca jest ok. Chodzi o ilość ofert dla danej aukcji lub ilość sprzedanych produktów na danej aukcji. Problem jest opisany tutaj: https://github.com/allegro/allegro-api/issues/1345#issuecomment-473345588 i poniżej tego wpisu były odpowiedzi.

glorifyingpeace commented 5 years ago

My z naszą aplikacją też nie wyrobimy. Dokumentacja i działanie poszczególnych metod pozostawia do życzenia. Dobrze było by przedłużyć termin przejścia.

yncki commented 5 years ago

Podpisuję się pod wszystkimi komentarzami powyżej. IMHO Rest API nie jest gotowe. Mapowania, brak kompatybilności, niespójne pola, niepełne informacje (np. ta informacja o sprzedaży i zmianie tytułu gdy sold = 0) i masa innych rzeczy (nawet dokumentacja nie jest gotowa, swagger błędny). A korzystający z api to nadal beta testerzy na 3 tygodnie przed wyłączeniem kolejnych metod. Nie wspomnę o ostatniej akcji z polami endedBy - nie wystarczy że to zostanie zaprogramowane po naszej stronie, ale to musi przejść fazę testów.

Mam też wrażenie że w większości issues tutaj zazwyczaj dyskusja kończy się tak samo :

przekazalem do odpowiedniego dzialu, jesli bedzie decyzja - poinformujemy was o tym

dodatkowo stale bot zamyka issues i ... nie dociera ta decyzja do nas albo dociera jedna na 10.

Tak naprawdę to przy większości issues zgłaszanych przez developerów można się smialo podpisac jako że każda sugestia niema na celu stworzenia problemu tylko jego rozwiązania i zrobienia z api naprawdę fajnego rozwiązania.

Podejrzewam też że w Allegro z rest api robicie wszystko co w waszej mocy aby szło to sprawnie, ale przykro mi - nie idzie to sprawnie. Przynajmniej ja to tak odbieram.

Dołączam prośbę o przesunięcie terminu.

KrzysztofStachyra commented 5 years ago

To i ja dołożę od siebie ;)

Najważniejsze to żeby wszyscy zrozumieli kto i dla kogo co tworzy. Allegro w założeniu powinno tworzyć API dla klientów i dla siebie, a my jako dostawcy korzystając z API tworzymy aplikację dla naszych i Waszych klientów. Jeśli któraś strona łamie tą zasadę to w efekcie cierpi klient końcowy i nasz i Wasz i klienci naszych klientów czyli Ci co kupują. Oni są najważniejsi bo są karmicielami nas wszystkich. Jeśli zatem sprzedawcy nie będą mieli zachowanej ciągłości bo my dajemy ciała co wynika z chaosu jaki wprowadzacie z przejściem to wylewają wiadro pomyj na sprzedawców ich klienci końcowi. To nie przysporzy Allegro większej prowizji. Wniosek jest taki, że przede wszystkim Allegro jako dostawca musi zrozumieć po co i dla kogo to tworzy - nie dla siebie - dla klientów.

Jeśli cel jest taki, żeby po cichu klienci przechodzili na Wasze systemy typu Menadżer sprzedaży lub inne to sorry ale nigdy się to Wam nie uda w większych firmach. Po prostu klient kończy proces w ERP czy się to komuś podoba czy nie to musi mieć te dane w tym miejscu przy pewnej skali. Kiedyś ktoś to u Was zrozumiał i próbował odpalić projekt, który upadł ale wtedy jakoś była chęć spotkania się i porozmawiania kto i czego potrzebuje - szkoda, że na chęciach się skończyło.

Pamiętam jak dziś jak ze 2 -3 lata temu dopytywałem średnio raz na kwartał czy są plany wprowadzania rest api jak dodawałem kolejne funkcje, ciągle było nie, nie ma. Potem bach z tygodnia na tydzień jak filip z konopii wyskoczyła jedna funkcja, która dzisiaj ma dużo bardziej opłakane skutki bo chcecie żebyśmy przechodzili na coś co sami określacie, że jest betą.

Może warto jednak pomyśleć o tym aby wysłuchać tych co tego API poza Wami używają i postarać się znaleźć kompromis bo jednak jak nasi klienci będą bardziej zadowoleni to Wy macie zwyczajnie z tego więcej kasy - zależności są bardzo proste.

dol1234 commented 5 years ago

Też jestem ciekaw, czy faktycznie wygasicie metody w tym terminie. Akurat przerzucam się na nowe API. Robię wstępną implementacje na podstawie dokumentacji (żadnym z dostępnych narzędzi nie udało mi się wygenerować klienta dla C#) i pozostawia ona sporo do życzenia (błędy i niespójności). Dodając do tego problem z dystrybucją tokenów w przypadku, gdy więcej niż jedna osoba pracuje na danym koncie robi się nerwowo:)

solokazama commented 5 years ago

Przesuniecie terminu jest porzebne.

Inaczej u nas bedzie rzez, bo na ta chwile musimy uzywac dwoch API, ktore nie sa ze wszystkim zgodne (nie wszystko da sie przemapowac).

bardzo prosze o przesuniecie, nie wiem szczerze mowiac co bedzie po 3 czerwca, jezeli wszystko (pomostowe 2 x API) nie bedzie u nas gotowe (raczej nie bedzie). Tym bardziej, ze sa i problemy ze starymi metodami (o jedej w innym issue zglosilem) i nowym (ktorego logika jest inna, wiec nie da sie 1do1 podmieniac, do tego pojawiace sie zmiany nie pomagaly).

nie wiem. prosciej byloby miec stara integracje, napisac nowa (majac kompletne restapi) i wdrozyc nowa. takie rzezbnienie na dwoch API (ktore nie sa ze soba kompatybilne - dane, logika) powoduje, ze nie wiem czy sie wyrobimy (bo system produkcyjny musi dzialac).

KrzysztofStachyra commented 5 years ago

Ja bym tylko sugerował, żeby taka decyzja zapadła wcześniej. Jeśli po naszej stronie uruchomimy dystrybucję wersji z ryzykiem, że czegoś nie dostesowaliśmy to jej nie cofniemy. A jeśli Wy w tym czasie zmienicie zdanie i nagle 01.06 napiszecie dobra jednak przesuwamy to dla nas to już jest musztarda po obiedzie. Klienci i tak poczują niezłą irytację.

FromAnyHole commented 5 years ago

Dzięki Ludzie !! Wszystko zostało już tu w sumie napisane ! A skoro dziś jest 13-ty, no i sam Pan Krzysztof się już wypowiedział, to tylko przypomnę, że:

PRZEZ 22 MIESIĄCE (tj. do połowy czerwca 2018) UTRZYMYWANO NAS W PRZEKONANIU, że interfejs WebAPI - POZOSTANIE PODSTAWOWYM INTERFEJSEM DOSTĘPOWYM, tyle !!

yncki commented 5 years ago

Pani @MartaNowaczyk kiedy można się spodziewać decyzji ?

ghost commented 5 years ago

Podbijam wątek i zgadzam się w 100% z poprzednikami. W naszym przypadku uda nam się przygotować aplikację działającą na RestAPI w narzuconym terminie, planujemy ją wydać do 24 maja, zgadzam się z @KrzysztofStachyra że taką decyzję potrzebujemy wcześniej, bo jeśli developerzy zaczną ją dystrybuować do swoich Klientów to będzie "po ptokach"

ArturBakAxl commented 5 years ago

Przedłużenie terminu jest koniczne

radoslawkoziol commented 5 years ago

Zdecydowanie za mało czasu dajecie, żeby to wszystko ogarnąć. Nie mamy nieskończonych zasobów. @MartaNowaczyk podpisuję się pod powyższymi prośbami o przedłużenie terminu.

gslpro commented 5 years ago

Allegro dziś rozesłało meile z przypomnieniem o wygaszaniu, także Ci co liczą na przedłużenie terminu chyba nie mają na co liczyć.

dol1234 commented 5 years ago

Allegro dziś rozesłało meile z przypomnieniem o wygaszaniu, także Ci co liczą na przedłużenie terminu chyba nie mają na co liczyć.

Witajcie bezsenne noce:)

riepa commented 5 years ago

Termin jest w tym momencie aktualny. Dziękujemy za sugestię. Jest to miejsce w którym możecie dodawać swoje argumenty za i przeciw. Na pewno wszystkim się przyjrzymy.

to się przyjrzeli

lkowol commented 5 years ago

@MartaNowaczyk możemy liczyć na jakiś merytoryczny feedback?

manhunto commented 5 years ago

Nasza aplikacja oparta o nowe rest api powstaje od końca poprzedniego roku. Podjęliśmy decyzję o stworzeniu nowej aplikacji, ponieważ strutkura i zaszłości architektoniczne WebAPI nie pozwoliłyby na łatwy refactor aktualnie używanej. Nasz system jest bardzo rozległy, zintegrowany z innymi podsystemami, serwisami zewnętrznymi, systemami ERP. Czas potrzebny na zaplanowanie, stworzenie, przetestowanie i wdrożenie produkcyjnie jest zbyt mały aby można to było zrobić w wyznaczonym terminie. Sam sposób wystawiania i jakie dane są potrzebne jest bardzo różny pomiędzy dwoma interfejsami. Chociażby definiowanie cenników dostawy jest kompletnie różne i wymusza inną implementację. Nawet z uwagi na to od kiedy pojawiła się stabilna wersja i ile od tego czasu minęło. Dołączam się do reszty deweloperów udzielających się w tym wątku i również uważam, że jest potrzebny dłuższy czas na przepięcie. Nasze zasoby też są ograniczone z uwagi na to, że trzeba dodatkowo utrzymywać klientów korzystających z WebAPI gdzie to też potrafi rownież działać różnie. Dodatkowo na minus jest to że zamówienia w rest api są jeszcze w wersji beta co zmusza nas utrzymywać stary podsystem do obsługi zamówień w aktualnym stanie i korzystać z dwóch api równocześnie.

Onixarts commented 5 years ago

Dokładnie taka sama sytuacja jest u nas. Nowe API to nie tylko nowe metody. Kod programów współpracujących z API powstaje latami, na założeniach serwisu są niejednokrotnie oparte różne rozwiązania wewnątrz programu. Zmiana API wraz z tymi założeniami przekreśla praktycznie możliwość wykorzystania poprzednich rozwiązań, które trzeba przepisywać/tworzyć od nowa. A gdzie testy tego wszystkiego? Gdzie testy kodu, który od wielu lat był dopieszczany aby wyeliminować różne sytuacje wyjątkowe. Nowe rozwiązania na bank nie zadziałają od strzału u ludzi w czerwcu i będzie ogólna katastrofa. I nie mówię tego jako pesymista, tylko realista - nie od dziś pracuję w tej branży, żeby nie wiedzieć czym się kończą takie wdrożenia na ostatnią chwilę ;). Pilotażowe zmiany w Allegro wprowadzane są stopniowo na wybranych sprzedawcach. My również chcielibyśmy oddać nowe rozwiązania części użytkownikom zaawansowanym, zanim program stanie się ogólnodostępny publicznie.

barthoos commented 5 years ago

Widze ze kazdy z nas ma dokladnie takie same odczucia. Przeprojektowanie i przepisanie aplikacji to jedno. A testowanie + zderzenie z rzeczywistoscia to drugie. Swietnie to widac w #1635 - ja szczerze powiedziawszy zaimplementowalem to rozwiazanie tak samo jak OP: przy wystawianiu produktu/grupy produktow (bywa ze 700x na raz) odpytuje w tle o produkt na podstawie EANu. Przez mysl by mi nie przeszlo, ze po N-tym zapytaniu zaczniecie strzelac sleepami, a to jest ewidentnie to co robicice. Takich kwiatkow wyjdzie z pewnoscia multum. A przy developingu nie strzelam od razu testami wydajnosciowymi..

Ja wiem, ze utrzymywanie 2x rozwiazan jest klopotliwe, ale pozbycie sie tego dlugu technologicznego nie moze byc tak latwe. Wg mnie nawet te 3 miesiace przesuniecia o ktore postuja niektorzy jest zbyt krotkim okresem. To powinno byc 6-12 miesiecy, zeby nowe rozwiazania zdazyly sie "ulozyc".

Maczuga commented 5 years ago

A może by tak po prostu skupić się najpierw na przeniesieniu całej funkcjonalności webapi a dopiero potem bawić się w wygaszanie? Bo takie pół na pół nikomu nic dobrego nie przyniesie. Przepisywać metody i tak trzeba będzie jeszcze kilka razy bo przecież inne też z czasem wygasną. U nas na chwilę obecną dalej kilka oddziałów jest zablokowanych z przejściem na rest, bo brakuje tam niektórych funkcji z webapi. Pomijając już fakt, że dalej nie ma jak się integrować z InPost na rest.

Onixarts commented 5 years ago

Inna sytuacja z dzisiaj, pobieranie ofert zakończonych, nagle liczba sprzedanych oraz dostępnych wynoszą 0, pomimo, że na tych aukcjach sprzedaż była. Tego typu kwiatków jest cała masa a w programach naszych muszą być takie sytuacje obsłużone. Gdyby nie testy na odpowiednich danych to by to wyszło dopiero u klientów. I bez testów u wybranych klientów szanse wykrycia wszystkich takich kwiatków są praktycznie znikome.

MartaNowaczyk commented 5 years ago

Jeśli macie konkretne przykłady błędów w udostępnionych zasobach przesyłajcie je proszę przez formularz kontaktowy. Standardowo pełne curle z requestem i responsem. Sprawdzimy i poprawimy jeśli będzie coś nie tak.

Onixarts commented 5 years ago

Bardziej chodzi mi o pokazanie, że w tym momencie API nie jest doskonałe, a co za tym idzie programy będą się po prostu sypały na każdym kroku.

MartaNowaczyk commented 5 years ago

@Onixarts Tym bardziej powinniście podesłać konkretne przykłady takich zdarzeń, zachowań, błędów w dokumentacji, abyśmy to poprawili.

TimothyKoval commented 5 years ago

@MartaNowaczyk Ale to nie my dostajemy 10-go wypłatę z Allegro

lkowol commented 5 years ago

@MartaNowaczyk takie ukierunkowanie "powinności" pokazuje, że uważacie nas jedynie za testerów problematycznego rozwiązania. Tak samo w tej dyskusji pojawiają się tylko odpowiedzi na zgłoszenia błędów, reszta (większość) komentarzy jest pomijana... To Wy powinniście posłuchać spójnego zdania odbiorców Waszego systemu i zmienić termin wygaszenia starego API.

anih commented 5 years ago

To np. gdzie mam szukać w dokumentacji informacji jakie error code mogą się pojawiać i w jakich przypadkach? No i czemu dokumentacja nie jest spójna z tym co faktycznie zwraca api? Przykład:

PUT /offers/8114593403/change-price-commands/2d09938e-b5a3-4252-a853-f0066511f3a7
json: {'input': {'buyNowPrice': {'amount': '163.21', 'currency': 'PLN'}}}
response: {"errors":[{"code":"ChangePrice.InvalidOfferStatus","message":"You can only change price in active offer.","details":null,"path":"buyNowPrice","userMessage":"You can only change price in active offer."}]}

Dokumentacja w ogóle o takim przypadku i o takim response nie mówi, a na dodatek aukcja była aktywna wchodząc poprzez stronę(możliwe że nie dokładnie ta z requestu ale wczoraj waliło taką ilością niby nieaktywnych aukcji że wyciszyłem błędy z REST-sh**) Więc jak my mamy w ogóle ogarnąć jak to ma działać jeśli nie mamy wszystkich możliwych przypadków. Dla usług SaaS to jeszcze da się to ogarnąć przy starcie, ale jeśli tworzysz apkę desktopową czy jakąs integrację na zlecenie to jesteś w czarnej d***.

KrzysztofStachyra commented 5 years ago

Podsumowując wracamy do starych złych praktyk, które były na FB a szkoda bo początki były obiecujące, żeby być uczciwym, przynajmniej częściej i bardziej imiennie, ktoś odpowiada. Wszystko było kolorowo, do momentu kiedy nie chcieliście nic narzucić bo nie było czego narzucić, jak już wydaliście coś w stylu "better done, than perfect" to stare przyzwyczajenia się odezwały. Wnioskuje, że skoro do dzisiaj nikt nie raczył się odezwać co dalej to termin jest utrzymany i pozostaje nam się modlić, że nic nie wybuchnie. Żeby klienci mogli zainstalować (często za pośrednictwem zewnętrznych firm nowe wersje na 03 (gdzie jeszcze weekend przed). To w tym tygodniu ludzie muszą dostać wersję.

martacronic commented 5 years ago

Mam wrażenie, że zespół pracujący nad API nie rozumie, że to wygaszenie bez jednoczesnej stabilnej, przetestowanej w 100% wersji REST API skończy się przede wszystkim stratami finansowymi sprzedawców. Z jednej strony dochód utracony, bo się aukcje nie wystawiają, nie wznawiają itp., a z drugiej błędy w aukcjach, które mogą spowodować straty ze względu na reklamacje, złe ceny, niezsynchronizowany stock itp. Osobom tworzącym oprogramowanie oparte na tym API często jest trudno udowodnić osobie, która z niego korzysta, że są błędy w API Allegro. Ciekawi mnie, czy gdyby zespół od API Allegro za te straty w wymiarze finansowym miał odpowiadać swoim osobistym majątkiem, to nie podszedł by bardziej rozważnie do wdrażania i wygaszania. To jednak nie są "zabawkowe" pieniądze z gry Monopoly...

solokazama commented 5 years ago

@MartaNowaczyk Prosze mi powiedziec jak mam przetestowac integracje ALLEGRO INPOST/ALLEGRO PACZKOMATY z waszym RESTAPI, skoro INPOST TEZ NIE JEST GOTOWY i nie mozna tego zrobic.

Co mam powiedziec klientom, ktorzy maja umowy z INPOSTem? Aby "wyslali CURLe"?

Po co w ogole ta fasada o "dyskusji", skoro praktycznie cale grono devow (duzych i malych), ktorzy tworza soft pod allegro API ma jedno zdanie - potrzeba jeszcze wiecej czasu. Skoro jednolity glos po naszej stronie nic nie daje - to moze darujmy sobie w ogole jakakolwiek dyskusje, odpalajcie hinduskie YOLO i niech sie dzieje.

barthoos commented 5 years ago

Poprosilbym o meska decyzje kogos po stronie Allegro i przekazanie nam jasnego, ostatecznego komunikatu co robimy. Powodow na przesuniecie jest az nadto i osobiscie nie wyobrazam sobie wyciecia WebAPI juz w czerwcu.

Ale to co robicie teraz jest dalece nieprofesjonalne. Mam przekazywac moim uzytkownikom, ze po 3-cim czerwca zawieszaja dzialalnosc na 3 miesiace (bo ja sie wczesniej nie wyrobie), czy nie? Umieszcze info, a Wy za 3x dni przesuniecie termin i bede robil niepotrzebne zamieszanie.

Takze prosba o jasny komunikat.

MagdalenaNieckula commented 5 years ago

Dorzucam się również do przesunięcia terminu wygaszenia starego api, pare miesięcy walczymy z Waszym nowym API a ciagłe błedy nadal zaskakują. Mieliśmy juz wszystko dopracowane, a dzisiaj znowu ciągłe niespodzianki z kategoriami. To nie działa dobrze....

MartaNowaczyk commented 5 years ago

Utrzymujemy aktualną datę wygaszenia WebAPI do obsługi i wystawiania oferty czyli 3.06.

Już niedługo opublikujemy pełen harmonogram wygaszania poszczególnych metod WebAPI i dostarczenia ich odpowiedników z naszej strony.

O wygaszeniu metod WebAPI do obsługi i wystawiania ofert informowaliśmy już dawno. Pierwsza informacja z datą wygaszenia 19 kwietnia 2019 pojawiła się już w zeszłym roku.

MartaNowaczyk commented 5 years ago

Wszelkie problemy z REST API do obsługi ofert zgłaszajcie w oddzielnych wątkach z pełnymi przykładami. Będziemy je oznaczać wyższym priorytetem.

MagdalenaNieckula commented 5 years ago

i my zaczęliśmy się do tego przygotowywać mamy gotowy produkt dla naszego klienta, a dziś znowu niespodzianka i masa błędów przy wystawianiu produktów praktycznie w każdej kategorii. Przecież to jest niesamowite, człowiek dopracowywuje rozwiązanie miesiącami, aż finalnie wchodzi zmiana, która rozwala połowę systemu. Jak my w przeciągu tych paru dni mamy sobie z tym poradzić?

FromAnyHole commented 5 years ago

@MartaNowaczyk - już niedługo, już niedługo... Czyli 99% opinii tych, dla których to podobno robicie - macie głęboko w Dooopie ??

riepa commented 5 years ago

@MagdalenaNieckula o jakiej zmianie w mówisz?

MagdalenaNieckula commented 5 years ago

@riepa drzewo kategorii zmienili, ale to nic. Dodali mnóstwo nowych rzeczy przy kategoriach i to na parę dni przed wygaszeniem starego Api:)

riepa commented 5 years ago

@MartaNowaczyk mógłbym prosić o opis zmian?

Maczuga commented 5 years ago

Utrzymujemy aktualną datę wygaszenia WebAPI do obsługi i wystawiania oferty czyli 3.06.

Już niedługo opublikujemy pełen harmonogram wygaszania poszczególnych metod WebAPI i dostarczenia ich odpowiedników z naszej strony.

O wygaszeniu metod WebAPI do obsługi i wystawiania ofert informowaliśmy już dawno. Pierwsza informacja z datą wygaszenia 19 kwietnia 2019 pojawiła się już w zeszłym roku.

Ale w dalszym ciągu nie rozumiecie, że zmuszacie na przejście na nieprzetestowane, niestabilne rozwiązanie? Przez ten rok nic się z tym nie poprawiło. Zmuszacie do korzystania z 2 API jednocześnie. Taki InPost dalej nie zrobiony (a już niby na marzec miał być). Na serio oczekujecie, że ludzie zaczną na hurra na tydzień przed przejściem na REST API puszczać surowy, nietestowany kod, który w dobrej mierze łączy się ze sprzedażą? Testowanie tego API to również masakra, bo nigdzie nawet nie pokusiliście się o rozpisanie kodów błędów (jak to było np. na WebAPI).

MartaNowaczyk commented 5 years ago

drzewo kategorii zmienili, ale to nic. Dodali mnóstwo nowych rzeczy przy kategoriach i to na parę dni przed wygaszeniem starego Api:)

@MagdalenaNieckula czy nie chodzi ci o rozbieżności na sandbox?

MagdalenaNieckula commented 5 years ago

Zgadza się:) Przepraszam za błedne wnioski.

imper86 commented 5 years ago

Ja tylko chciałbym zauważyć, że dużo osób wspomina o metodach beta, integracji z inpostem, obsłudze sprzedaży. No macie generalnie rację, tylko... 3-go czerwca wyłączają metody związane z wystawianiem i zarządzaniem ofertami, więc nie ma to nic wspólnego z obsługą sprzedaży.

Aż sprawdziłem kiedy zmieniałem u siebie metodę do wystawiania draftu oferty z wersji beta na public, no i git mówi mi 26.09.2019, a komunikat na githubie jest tu: https://github.com/allegro/allegro-api/issues/652#issue-364034176

Nie bronię allegro, bo wychodzę z założenia, że jeżeli tak duża ilość osób zgłasza potrzebę przesunięcia tego terminu to powinni się po prostu na to zgodzić. Ale nie liczcie na to, że używanie nietrafionych argumentów kogoś tam przekona. W moim przypadku obsługa wystawiania i zarządzania aukcjami chodzi już od wielu miesięcy na REST api i nie mam z tym żadnego problemu.