Wersjonowanie

AstroWay API używa wersjonowania przez URL: wersja jest określona w ścieżce zapytania. Jest to prostsze niż wersjonowanie przez nagłówki i dobrze się cache’uje przez proxy.

https://api.astroway.info/v1/chart

SemVer dla API

Dostosowujemy się do semantyki semver.org:

• MAJOR (v1 → v2): zmiany łamiące. Stara wersja kontynuuje pracę przez co najmniej 12 miesięcy po wydaniu nowej.
• MINOR: nowe endpointy, nowe opcjonalne pola. Zawsze kompatybilne wstecz.
• PATCH: poprawki błędów, usprawnienia dokładności. Widoczne przez nagłówek X-Api-Version: 1.12.3 w odpowiedzi.

Co nie jest breaking change

• Dodawanie nowego endpointu
• Dodawanie nowego opcjonalnego pola w ciele zapytania (request body)
• Dodawanie nowego pola w odpowiedzi
• Udoskonalenie tekstu komunikatów o błędach (kody code pozostają stabilne)
• Zmiany dokładności obliczeń w ramach zadeklarowanych ±1” (planety) / ±1’ (domy)
• Zwiększenie limitu rate limit lub credit budget w Twoim planie

Oznacza to, że Twój kod nie powinien ulegać awarii przy dodawaniu nowego pola w odpowiedzi. Parsuj tylko to, czego potrzebujesz, ignoruj resztę.

Co jest breaking change (tylko w major release)

• Usunięcie lub zmiana nazwy endpointu
• Usunięcie lub zmiana nazwy pola w odpowiedzi
• Zmiana typu pola (np. number → string)
• Zmiana semantyki pola (co oznacza to samo imię)
• Zmiana code w odpowiedzi o błędzie
• Zaostrzenie walidacji, które może złamać wcześniej poprawne zapytania

Changelog

Wszystkie zmiany - w Changelog. Wersje minor co 2-4 tygodnie, patchy na bieżąco.

Subskrybuj aktualizacje:

• RSS: https://api.astroway.info/changelog/rss.xml
• Email: Settings → Notifications → Product updates w dashboard

Polityka wycofywania

Gdy pole lub endpoint staje się deprecated:

1. Ogłaszamy w changelog + email-notice
2. W odpowiedzi pojawia się nagłówek Deprecation: Sun, 01 Nov 2026 00:00:00 GMT (standard RFC 8594)
3. Wycofane API działa przez co najmniej 12 miesięcy
4. Usunięcie: tylko w następnym major release