[NEWS] GET /sale/offers od dziś w wersji public

[PawelTaberski]

AKTUALIZACJA:

[6.05.2019] Przywróciliśmy pola publication.startedAt i publication.endedAt w wersji public. #1592 Wersję beta utrzymamy na pewno do 20.05.
.....................
[30.04.2019] Jesteśmy w trakcie dodawania pól publication.startedAt i publication.endedAt do wersji public GET /sale/offers. W związku z tym, wersję beta utrzymamy do czasu wprowadzenia tej zmiany, a nie tak jak pisaliśmy wcześniej, do 6.05.

........................
[18.04.2019] Zakończyliśmy okres testowy dla zasobu GET /sale/offers do zarządzania ofertami i dziś udostępniliśmy go w wersji public. Wersję beta będziemy wspierali do 6.05.2019. W tym okresie możecie systematycznie przechodzić na wersję public.
Aby przejść na nową wersję wystarczy w nagłówku ‘accept’ wywołania zmienić wartość:

‘application/vnd.allegro.beta.v1+json’ na ‘application/vnd.allegro.public.v1+json’

Ważne! W wersji public nie zwracamy pól publication.startedAt i publication.endedAt.

5 sierpnia 2019 usuniemy metody WebAPI do zarządzania listą ofert sprzedającego, które dziś oznaczamy jako deprecated. Dotyczy to metod:

• doGetMySellItems,
• doGetMySoldItems,
• doGetMyNotSoldItems,
• doGetMyFutureItems,
• doMyAccount2,
• doMyAccountItemsCount,

Dlatego już teraz odradzamy użycia tych metod w nowych rozwiązaniach i zalecamy migrację na REST API.

[PhotoSoft]

Ważne! W wersji public nie zwracamy pól publication.startedAt i publication.endedAt.

Czy to jest jakiś kiepski żart?! Komu to przeszkadzało? Data wystawienia i zakończenia są mi (i pewnie nie tylko mnie) niezbędne do prawidłowego działania aplikacji, m.in. filtrowania aukcji w bazie na trwające / zakończone.

Czy wy w ogóle myślicie o aplikacjach, które muszą wykonać migrację i z początku obsługiwać oba API, aby Klienci mogli się bez problemu przestawić? Dwa tygodnie temu skończyłem integrować RestApi, gdzie te pola były i teraz przez waszą durnowatą niezapowiedzianą zmianę przestała działać kluczowa funkcjonalność w mojej aplikacji!

Jak mam teraz pobrać obie te daty przez RestApi?

[lukada4100]

Podłączam się. Decyzja by zlikwidować możliwość pobrania przez RestApi daty wystawienia i zakończenia oferty, jest co najmniej lekko ekstrawagancka.

Jakiś czas temu ( #1210) gdy zgłaszałem niekonsekwencję polegającą na tym, że daty wystawienia i zakończenia oferty zwracane są za pomocą get /sale/offers, a nie get /sale/offers/{OfferId} pisaliście, że pracujecie nad tym jak to uspójnić. Okazało się, że uspójnienie będzie polegało na tym, że dane te nie będą zwracane ani przez jedną ani drugą metodę?

Póki co, przy braku wartości startedAt i endedAt aplikacja mi leży.

[PhotoSoft]

Zwrócę uwagę na jeszcze jeden problem. Do 12h od wystawienia aukcji można zmienić np. kategorię. Skąd teraz mam wiedzieć czy minęło już te 12h czy nie skoro API nie zwraca już daty wystawienia?

[lukasnet]

Znowu chcecie usunąć kolejną metodę nie zapewniając nam odzwierciedlenia jej działania w rest :(
W dalszym ciągu brak informacji o liczbie sprzedanych przedmiotów od początku istnienia oferty a nie tylko z 30 dni, oraz brak początkowej ilości przedmiotów w ofercie.
Mam nadzieję że do czasu usunięcia tych metod te informacje pojawią się w rest, bo inaczej nie da się przejść na nowe api!

[yncki]

Bardzo się staram nie narzekać, ale ja pier.....

[FromAnyHole]

@PhotoSoft / @lukada4100 / @lukasnet / @yncki - tego nie wolno im odpuścić, jak będzie trzeba urządzimy protest albo zadymę, dość tego - dla kogo oni to w ogóle robią, dla siebie ?? Aby pensję potem odebrać...?

[yncki]

Jedyne wyjscie jakie widze to zgloszenie tego co tu sie dzieje do prasy, kilka portali podlapie i moze to cos da. Jak nie wiadomo o co chodzi, to chodzi o kase. Ogolne podejscie jest dziwne, bo api powinno byc friendly dla developerow a jest wrecz przeciwnie. Moze dla siebie to API robia.... Mysle tez, ze tego typu zabiegi sa na reke samemu allegro, bo np. nie majac czasu startu, uzytkownik koncowy niema informacji o np. starych ofertach w ktorych jest brak sprzedazy - za ktore allegro kosi kase ( 10gr 10 dni ), przy takiej skali to sie pewnie uzbiera. Ale to tylko domysly.

[lukasnet]

@PawelTaberski Proszę podać nam kto jest odpowiedzialny za podejmowanie takich kluczowych decyzji, do kogo się zgłaszać bezpośrednio, abyśmy wiedzieli potem kogo wywieźć na taczce ;) bo ta osoba zabiera się za zmiany od d...y strony.

[PawelTaberski]

Podajcie mi proszę do czego są wam potrzebne te pola do czego je używaliście. Oczywiście przekażę sugestię o przywróceniu tych pól, ale prosiłbym o jakieś przykłady ich zastosowań. Postaram się to jak najlepiej przekazać do zespołu, który za to odpowiada.

[FromAnyHole]

@yncki / @lukasnet - przecież dokładnie wiadomo o co tutaj chodzi, poza tym oni sobie patrzą w statystyki użycia konkretnych metod czy zasobów, no i wszystko staje się jasne ! Potem czytamy tu tylko te bzdury...

[martacronic]

@PawelTaberski dla mnie osobiście te pola są potrzebne do określania aukcji, które będą podlegały opłacie utrzymaniowej. Mogę przez limit i offset wtedy szybko sprawdzić wszystkie. Jeśli tych pół nie będzie, to będę korzystała z metody GET /sale/offers/{offerId} i o każdą aukcję, co znacząco zwiększa ilość zapytań i czas jaki jest potrzebny na wykonanie takiej operacji.

[yncki]

@PawelTaberski

1. Do automatyzacji, czy można np. zmienić tytul oferty
2. Do automatyzacji - oferty do automatycznego zamkniecia z powodu braku oplacalnosci ( np. 3 miesiace wisi bez sprzedazy - sprzedawco zrob cos , albo obniz cene, albo zakoncz oferte itp )
3. Wylapanie ofert ktore wymagaja uwagi, tez czesciowo powiazane z analityka
4. Lepsza integracja z allegro, majac takie dane mamy wieksze pole do popisu, nawet do glupich bledow kiedy sie oferta zakonczyla itp nie zwiekszajac obciazenia api.

[yncki]

jeszcze mala sugestia skoro juz o tym mowa, o wiele lepiej byloby dorobic 3 opcje

publication.started_at
publication.ended_at

i cos ala
publication.first_started_at ( data pierwszej aktywacji )

[lukada4100]

dodam jeszcze:

• do statystyk: ile ofert wystawiłem w danym okresie. Gdy mam kilka tysięcy ofert w miesiącu to dość istotne.
• do automatycznej obniżki starych ofert, które się nie sprzedają.

[PhotoSoft]

@PawelTaberski

1. Filtrowanie aukcji na trwające / zakończone
2. Wyłapywanie niesprzedających się towarów
3. Kontrolowanie opłaty utrzymaniowej
4. Wznawianie zakończonych aukcji po stronie aplikacji

[PawelTaberski]

Dziękuję wszystkim za dane przekażę je i jak tylko otrzymam jakieś informacje dam znać.

[lukada4100]

Albo przynajmniej zróbcie, żeby zasób publication w get /sale/offers, i w get /sale/offers/{OfferId} był taki sam i w obu przypadkach zwracał endedBy.

Do czego mi to potrzebne?
Przed zmianami, żeby wyłapać oferty, które zakończyły się przez expiration w danym okresie czasowym zaciągałem za pomocą get /sale/offers zamknięte oferty (wszystkie, co oczywiście jest rozrzutnością, ale innej metody nie było więc pal sześć), po swojej stronie, sprawdzając endedAt wybierałem te, które zamknęły się w interesującym mnie okresie czasowym, a porównując endingAt z endedAt odrzucałem te, które z jakiś powodów zostały zamknięte przez użytkownika.

A teraz co? Żeby sprawdzić, czy wygasła sama, czy zamknął ją użytkownik, każdą jedną z kilkuset ofert muszę pobrać przez get /sale/offers/{OfferId} i sprawdzić endedBy?

Nie wspominając oczywiście nawet o tym, że wyłapanie tych, które zostały zamknięte przez użytkownika w danym okresie, w ogóle nie jest obecnie możliwe.

[PawelTaberski]

@lukada4100 Przekazałem również i twoją sugestię. Jak tylko otrzymam jakieś informacje dam znać.

[KrzysztofStachyra]

My używamy do sortowania ich wg tych, które się kończą. Często są to sezonowe produkty i nie zawsze nasi klienci mają jakieś automaty do ich wznawiania.
Na tych datach bazują filtry aplikacji desktopowej.

[PawelTaberski]

Dzięki za informacje z uzasadnieniem. Oczywiście również ją przekażę. Jak tylko otrzymam jakąś decyzję to wrócę do was z informacją.

[damianSzechlicki]

@PawelTaberski od 6 maja wersja beta nie będzie wspierana czy zostanie wyłączona? w sensie czy będzie będzie można dalej z Niej korzystać i mieć dostęp do tych pól?
Jeżeli nie, to czy można wydłużyć ten okres dopóki nie poznamy decyzji?

[PawelTaberski]

@damianSzechlicki Nie ma takiej potrzeby :-)
Otrzymałem właśnie informację, że pola te będą przywrócone i będziemy je zwracali w wersji public. Bardzo dziękuję wszystkim zaangażowanym:
@PhotoSoft @martacronic @yncki @lukada4100 @KrzysztofStachyra
za wasze uzasadnienia dzięki czemu pola te będą przywrócone. W poniedziałek wyślemy w tej kwestii oficjalny komunikat.
Jeszcze raz bardzo dziękuję za zaangażowanie i konkretne przykłady zastosowań.

[PhotoSoft]

Wspaniała wiadomość :) Dziękujemy.

Mnie i przede wszystkim moim Klientom do szczęścia brakuje jeszcze tylko wersjonowania kategorii i parametrów #1554

[imper86]

@PawelTaberski mam nadzieję, że będzie to przed 6 maja? Żeby nie było przerwy w "dostawie" tych danych :)

[PawelTaberski]

@imper86 Tak, jak najbardziej ciągłość ma być zachowana.

[MartaNowaczyk]

AKTUALIZACJA:
Jesteśmy w trakcie dodawania pól publication.startedAt i publication.endedAt do wersji public GET /sale/offers. W związku z tym, wersję beta utrzymamy do czasu wprowadzenia tej zmiany, a nie tak jak pisaliśmy wcześniej do 6.05. Chcemy mieć pewność, że ciągłość będzie zachowana.

Gdy zakończymy prace i zaczniemy zwracać te pola, na pewno was o tym poinformujemy.

[neldh]

oczywiście wersji public nie wyłączacie wobec tego i w tej chwili obie wersje będą zwracac to samo?

[MartaNowaczyk]

@neldh Jeśli dodamy te pola do wersji public jeszcze przez jakiś czas obie wersje będą zwracały te same dane. W tej chwili wersja public nie zwraca jeszcze tych pól.

[MartaNowaczyk]

#1592