Czy ogólnie należy opracować bibliotekę klientów dla usług REST, aby zapobiec awariom interfejsu API?

Mamy projekt, w którym ten sam zespół opracuje kod interfejsu użytkownika, ale w innym języku (Python / Django) niż warstwa usług (REST / Java). Kod dla każdej warstwy jest zamykany w różnych repozytoriach kodów i które mogą podlegać różnym cyklom wydania. Próbuję wymyślić proces, który zapobiegnie / ograniczy przełamywanie zmian w warstwie usług z perspektywy warstwy interfejsu użytkownika.

Myślałem o napisaniu testów integracyjnych na poziomie warstwy interfejsu użytkownika, które będziemy uruchamiać za każdym razem, gdy budujemy interfejs użytkownika lub warstwę usług (używamy Jenkinsa jako naszego narzędzia CI do tworzenia kodu, który jest w dwóch repozytoriach Git) i jeśli są awarie, wtedy coś w warstwie usług zepsuło się i zatwierdzenie nie jest akceptowane.

Czy dobrym pomysłem byłoby (czy jest to najlepsza praktyka?), Aby twórca warstwy usług utworzył i utrzymywał bibliotekę kliencką dla usługi REST, która istnieje w warstwie interfejsu użytkownika, którą będą aktualizować za każdym razem, gdy nastąpi przełomowa zmiana w ich interfejs API usługi? Można sobie wyobrazić, że mielibyśmy wtedy przewagę nad statycznym interfejsem API, na którym opiera się kod interfejsu użytkownika. Jeśli interfejs API biblioteki klienta ulegnie zmianie, kod interfejsu użytkownika nie zostanie skompilowany (więc wcześniej dowiemy się, że nastąpiła przełomowa zmiana). Nadal przeprowadzałbym testy integracji po zbudowaniu interfejsu użytkownika lub warstwy usług, aby dodatkowo sprawdzić, czy integracja między interfejsem użytkownika a usługą (usługami) nadal działa.

Zasadniczo w przypadku metod API, które odchodzą, wybierz konwencję i „przestarzałe”, szczególnie gdy tylko pełny, zastępczy interfejs API będzie dostępny i przetestowany. Pozostaw stary interfejs API na swoim miejscu (zasadniczo), ale oznacz metadane podpisu metody lub wstaw zdarzenie rejestrowania, aby można było wyraźnie zidentyfikować użycie.

Logowanie w interfejsie API usługi to jedno, ale alarmowanie klientów korzystających z usług to coś innego. W przypadku REST nie sądzę, aby istniała solidna, standardowa praktyka. Klienci interfejsu API FourSquare mogą wykryć przestarzałe metody, nawet jeśli wywoływana metoda zakończy się powodzeniem (kod HTTP 200, jednak parametr errorType zostanie ustawiony na „przestarzałe”). Być może rozsądna strategia zapewniania konsumentom korzystającym z oferty wiedzy o przestarzałej metodzie w interfejsie API bez powodowania uszkodzeń.

https://developer.foursquare.com/overview/respactions

W wytycznych interfejsu API sugeruj datę lub numer wersji kompilacji, w której przestarzały interfejs API zostanie całkowicie usunięty. Gdy zapoznasz się z naszą strategią wycofania, będziesz chciał ostrzec konsumentów o interfejsie API na temat proponowanej strategii (w jaki sposób mogą odkryć przestarzałe metody, jak przejść na zastępczy interfejs API i kiedy przestarzałe API nie będzie już dostępne, jeśli oczyszczone podczas czyszczenia interfejsu API) i uzyskaj od nich informacje zwrotne, aby upewnić się, że proces jest korzystny dla wszystkich.

Wersjonowanie interfejsu API to kolejna możliwość. Po wdrożeniu nowej wersji pozostaw również starą wersję aktywną i zezwól na negocjacje za pośrednictwem żądania. Jeśli zachowujesz najnowsze 2 lub 3 wersje, kod interfejsu użytkownika można aktualizować we własnym tempie.

Są co najmniej trzy pytania na raz, zróbmy je pojedynczo

• „czy warto mieć bibliotekę klienta dla usługi REST?”

Najprawdopodobniej tak, o ile nie chcesz, aby arbitralne połączenia REST były rozproszone po całym kodzie interfejsu użytkownika.

• „czy dobrym pomysłem jest pozwolenie twórcy warstwy usług na tworzenie i utrzymywanie biblioteki lib?”

To zależy od osób w twoim zespole. Opiekun interfejsu API powinien znać zarówno rzeczy dostępne w warstwie usług, jak i wymagania dotyczące warstwy interfejsu użytkownika. Tak więc może to być osoba z warstwy usług lub jedna z warstwy interfejsu użytkownika, lub (w zależności od wielkości i innych zadań) osoba niezależnie od obu zespołów.

• [czy skorzystamy z faktu, że] „jeśli interfejs API biblioteki klienta się zmieni, kod interfejsu użytkownika nie zostanie skompilowany”

Czy nie powiedziałeś, że interfejs użytkownika zostanie napisany w języku Python? To nie jest język o typie statycznym, więc nie spodziewałbym się natychmiastowej przerwy w kompilacji po zmianie interfejsu API. Zakładam, że w tym momencie popełniłem błąd i masz tutaj statycznie wpisany interfejs API - możesz uzyskać tutaj pewne korzyści, o ile kompilacja nie ulegnie awarii, gdy tylko dodasz nowe funkcje (takie jak nowe parametry opcjonalne) do interfejsu API. W przeciwnym razie wygenerujesz wiele niepotrzebnych kosztów ogólnych dla swojego zespołu.