Zasady dotyczące zmian powodujących niezgodność
Zasady dotyczące zmian powodujących niezgodność
Dowiedz się, jak ElevenLabs definiuje zmiany powodujące niezgodność w API.
Przegląd
Aby pogodzić szybki rozwój ze stabilnością, ElevenLabs jasno określa, co uznaje za zmiany niekompatybilne w API. Poniżej wyjaśniamy, co uznajemy za takie zmiany, a czego nie.
Wszystkie aktualizacje i zmiany API publikujemy co tydzień w dzienniku zmian.
Zmiany odpowiedzi i schematów
Starannie rozróżniamy zmiany addytywne i odejmujące w odpowiedziach API. Dodanie nowych pól do modeli odpowiedzi nie jest uznawane za zmianę niekompatybilną. Podczas integracji z naszym API klient API musi ignorować nierozpoznane pola i nie stosować ścisłego sprawdzania typów odpowiedzi API. Prawie wszyscy nowocześni klienci API robią to domyślnie.
Usunięcie istniejących pól odpowiedzi lub zmiana ich struktury to zmiana niekompatybilna, ponieważ aplikacje klienckie mogą polegać na obecności tych pól i ich oczekiwanym formacie.
Zmiany parametrów
Zmiany parametrów API podlegają ścisłemu modelowi kompatybilności. Dodanie wymaganych parametrów do istniejących endpointów zawsze jest zmianą niekompatybilną, ponieważ istniejące wywołania klienta nie przejdą walidacji. Dodanie parametrów opcjonalnych (z wartościami domyślnymi lub wyraźnie oznaczonych jako opcjonalne) nie jest jednak zmianą niekompatybilną, ponieważ istniejące wywołania klienta mogą działać bez zmian. Podobnie zmiany typów lub formatów parametrów albo uczynienie wcześniej opcjonalnych parametrów wymaganymi uznajemy za niekompatybilne, ponieważ zmieniają kontrakt oczekiwany przez klientów.
Zmiany endpointów i ścieżek
Usunięcie całych endpointów lub ścieżek API z natury jest zmianą niekompatybilną, ponieważ aplikacje klienckie wywołujące te endpointy otrzymają błędy. Endpointy mogą zostać oznaczone jako wycofywane, ale nie usuniemy ich bez odpowiedniego poinformowania wszystkich użytkowników, których to dotyczy.