Skip to content

Changelog

Zmiany w API i w tej dokumentacji, najnowsze na górze. Przy każdym wpisie widać, skąd o zmianie wiemy - bo to zmienia, jak należy ją traktować.

  1. wykryte przez nasdokumentacja

    Przyrostowa synchronizacja przez timestamp - udokumentowana granica

    Nowe recipe 07 opisuje mechanizm, który obcina ruch o rzędy wielkości: zapisujesz api.timestamp z odpowiedzi i wysyłasz go jako parametr timestamp w kolejnym żądaniu, dostając tylko to, co się zmieniło. Zmierzone na /v2/incidents: 87 rekordów bez filtra, 2 z filtrem.

    Co to dla Ciebie znaczy, i to jest ważne: granica jest inkluzywna (ut >= timestamp), nie wyłączna. Żądanie z timestamp równym ut rekordu nadal go zwraca. Czyli każda synchronizacja dostarcza ponownie rekordy z poprzedniej granicy, a naiwna pętla INSERT duplikuje wiersz przy każdym odpytaniu.

    Zapis musi być idempotentny - klucz na id i upsert. To nie jest defekt, to zabezpieczenie: gwarantuje, że nie przegapisz rekordu zapisanego w tej samej sekundzie co Twój kursor.

  2. wykryte przez nasdokumentacja

    Endpoint wymiany tokenu jest wreszcie w referencji API

    GET /v2/oauth, czyli wymiana client_id i secret_key na token, nie występuje w opublikowanym dokumencie OpenAPI - mimo że jest pierwszą rzeczą, jakiej potrzebuje każdy integrator. Dopisaliśmy go do publikowanej specyfikacji, więc widać go w referencji razem z parametrami, przykładową odpowiedzią i działającym "Try it out".

    Kontrakt potwierdzony na produkcji: GET z client_id i secret_key w query stringu.

    To nie pochodzi ze specyfikacji zespołu API. Ten opis dopisaliśmy my, na podstawie zachowania produkcji. Traktuj kształt jako sprawdzony, a źródło jako nasze. Gdy zespół API opublikuje endpoint u siebie, nasza wersja zniknie.

    Przy okazji: GET /v2/sports, GET /v2/areas i GET /v2/languages odpowiadają bez tokenu (zmierzone: HTTP 200 z pełnymi danymi dla nieprawidłowego tokenu, celowe wg zespołu). W referencji mają teraz puste security, więc "Try it out" na nich działa, zanim zdobędziesz credentiale.

  3. wykryte przez nasdokumentacja

    Definicje 46 sportów dostępne jako dane referencyjne

    Sekcja Data reference pokazuje teraz statusy, wyniki, detale, incydenty i typy tabel dla 46 aktywnych sportów, pobrane z GET /v2/sports/{id} i odświeżane codziennie.

    Wcześniej te listy istniały tylko w wewnętrznej dokumentacji i były utrzymywane ręcznie, więc rozjeżdżały się z API. Teraz są generowane, a każda zmiana kontraktu otwiera Pull Requesta z opisem po nazwach, nie po identyfikatorach.

    Co to dla Ciebie znaczy: mapowania status_id, result id i incident_id możesz brać ze strony sportu, zamiast kodować je z pamięci. Uwaga, że zestaw pól różni się per sport - /v2/statuses zwraca 369 pozycji dla wszystkich sportów razem i nie ma pola sport_id, więc podział na sporty pochodzi z definicji sportu, nie z tego endpointu.