Nadmierna centralizacja logiki biznesowej
Jednym z częściej opisywanych problemów jest umieszczanie w bramce API logiki biznesowej, która powinna pozostać w warstwie usług. Prowadzi to do sytuacji, w której bramka staje się trudnym do utrzymania punktem centralnym, którego zmiana wymaga koordynacji między wieloma zespołami odpowiedzialnymi za różne usługi.
Brak spójnej polityki limitów ruchu
Niespójne konfiguracje rate limitingu pomiędzy poszczególnymi endpointami mogą prowadzić do nieprzewidywalnego zachowania systemu pod obciążeniem. W dokumentacjach dobrych praktyk zaleca się definiowanie limitów na poziomie centralnej konfiguracji bramki, z możliwością nadpisywania wartości domyślnych dla wybranych endpointów w uzasadnionych przypadkach.
Niedostateczna dokumentacja zmian w API
Brak aktualnej dokumentacji dotyczącej wprowadzanych zmian w interfejsach API bywa źródłem problemów integracyjnych po stronie konsumentów API. Regularna aktualizacja specyfikacji (np. w formacie OpenAPI) oraz jasne komunikowanie terminów wycofania starszych wersji ogranicza ryzyko niezgodności po stronie integrujących się systemów.
Czy bramka API powinna zawierać logikę biznesową?
W większości opisywanych podejść zaleca się ograniczenie logiki na poziomie bramki do funkcji infrastrukturalnych, pozostawiając logikę biznesową w warstwie usług.
Jak uniknąć niespójności limitów ruchu między usługami?
Pomocne jest scentralizowane zarządzanie konfiguracją limitów na poziomie bramki API zamiast definiowania ich niezależnie w każdej z usług wewnętrznych.