Wycofania
Bird wycofuje trzy różne rzeczy i każda zachowuje się inaczej. Pole żądania zostaje przemianowane, a stara nazwa działa obok nowej. Parametr zapytania zostaje zastąpiony lepszym filtrem i dalej działa bez zmian. Struktura ciała żądania zostaje zastąpiona nową strukturą, a stara jest nadal akceptowana. W każdym przypadku żądanie, które z nich korzysta, wraca z nagłówkiem odpowiedzi Deprecation, który o tym informuje.
Nagłówek
Odpowiedź na żądanie zawierające wycofane pole, parametr lub strukturę ciała zawiera:
| Nagłówek | Wartość |
|---|---|
| Deprecation | Data ogłoszenia wycofania, na przykład @1786579200 |
| Link | <https://bird.com/docs/api/deprecations>; rel="deprecation" |
Wartość Deprecation wskazuje, kiedy stara nazwa została wycofana, zgodnie z RFC 9745. Nie podaje daty usunięcia.
Odpowiedzi na żądania używające wyłącznie aktualnych nazw nie zawierają żadnego z tych nagłówków, więc sam nagłówek jest sygnałem: jeśli nigdy go nie widzisz, nic z tego, co wysyłasz, nie jest wycofane.
Brak daty usunięcia
Bird nie wysyła nagłówka Sunset, ponieważ data usunięcia nie jest jeszcze znana. Zastąpiona nazwa jest usuwana dopiero po ustaniu jej użycia. Bird kontaktuje się z dotkniętymi klientami przed usunięciem.
Traktuj nagłówek Deprecation jako zachętę do migracji we własnym tempie. Nie rozpoczyna on odliczania do usunięcia.
Przemianowane pole żądania
Zastąpiona nazwa pola zachowuje się dokładnie tak jak wcześniej:
- Nadal jest akceptowana w żądaniach i nadal zapisuje tę samą wartość.
- Nadal jest zwracana w odpowiedziach obok nazwy, która ją zastąpiła.
- Aktualna nazwa ma pierwszeństwo, jeśli wyślesz obie, więc możesz migrować jedno miejsce wywołania na raz bez nadpisywania nowej nazwy przez starą.
Przemianowane nazwy pól są pominięte w tej dokumentacji, a oficjalne SDK-i udostępniają tylko aktualne nazwy. Aktualizacja SDK przenosi więc żądania na aktualną nazwę pola.
Wycofany parametr zapytania
Parametr zapytania jest wycofywany, gdy zastępuje go lepszy filtr. Różni się od przemianowanego pola na trzy istotne sposoby:
- Pozostaje opublikowany wszędzie. Usunięcie go z dokumentacji i SDK-ów zepsułoby kod wywołujący, który już go wysyła, więc zachowuje swój wiersz w tej dokumentacji, swoje pole w każdym SDK, swoją flagę w CLI i swój wpis w schemacie narzędzia MCP. Aktualizacja SDK nie przeprowadza migracji.
- Nie ma części odpowiedzi. Parametr zapytania pojawia się wyłącznie w żądaniu, więc nic w ciele odpowiedzi się nie zmienia i nie ma nowej nazwy do odczytania.
- Zamiennik nie musi być jednym parametrem. Filtr bywa zastępowany parą, więc opis parametru wskazuje, czego użyć zamiast niego, a nie wskazuje jednego następcy.
Ponieważ aktualizacja nie przeprowadza migracji, nagłówek Deprecation jest jedynym sygnałem, który otrzymasz. Sprawdź opis parametru w tej dokumentacji: wycofany zaczyna się od Deprecated: i podaje jego zamiennik.
Zastąpiona struktura ciała żądania
Endpointy wysyłki zbiorczej, POST /v1/sms/batches i POST /v1/email/batches, kiedyś przyjmowały partię jako samodzielną tablicę JSON na najwyższym poziomie. Teraz przyjmują obiekt, którego tablica messages zawiera te same elementy, czyli strukturę opisaną w tej dokumentacji. Żądanie, którego ciało nadal jest samodzielną tablicą, działa dokładnie tak jak wcześniej i wraca z nagłówkiem Deprecation. Oficjalne SDK wysyłają obiekt messages, więc aktualizacja SDK przenosi żądania na aktualną strukturę.
Migracja
- Obserwuj nagłówek Deprecation w swoich odpowiedziach.
- Znajdź żądanie, które go wywołało, i sprawdź w tej dokumentacji opis operacji, aby zobaczyć aktualne nazwy i strukturę żądania.
- Przejdź na aktualną nazwę lub strukturę. Po migracji wysyłaj już tylko aktualną formę.
Aktualne wycofania
| Operacja | Wycofane | Użyj zamiast |
|---|---|---|
| WhatsApp: lista wiadomości | parametr zapytania phone_number | to lub from |
| SMS i email: utwórz partię wiadomości | ciało żądania jako samodzielna tablica | obiekt z messages |
Żadne przemianowane pole nie jest obecnie wycofane. Numer telefonu kontaktu to phone_number, a adres e-mail odbiorcy weryfikacji to email wewnątrz to; każda inna pisownia któregokolwiek z nich jest odrzucana jako błąd walidacji we wszystkich operacjach, które je przyjmują.
to i from na liście wiadomości WhatsApp dopasowują po jednym końcu wiadomości i każdy akceptuje numer telefonu lub identyfikator użytkownika w zakresie firmy. phone_number dopasowywał kontakt w obu kierunkach, więc wyszukiwanie niezależne od kierunku wymaga obu filtrów, po jednym żądaniu na każdy.
Powiązane zasoby
Kontynuuj z dokumentacją, przewodnikami i przykładami dotyczącymi tego tematu. Zasoby są w języku angielskim.
Zrozum koncepcjęShould I use a Bird SDK or call the API directly?Podążaj ścieżką naukiBuild your first integrationPrzewodnik wdrożeniowySend your first email
Uzyskaj brief wdrożeniowy