Dobre narzędzia do wersjonowania modeli REST dla Javy

Question

Szukam dobrych narzędzi do obsługi pomocy technicznej zmieniającej wersję modelu używanego w usługach REST. Moje wymarzone narzędzia byłoby zrobić coś takiego:

• My POJO + w wersji 1.0 config/transformatora => usługa z 1,0 mojego modelu
• Moje pojo + wersja 1.1 config/transformator => usługa z 1,1 mojego Model

W moim konkretnym przypadku nie muszę robić odwrotną transformację jak moja usługa REST zapewni tylko wyszukiwanie danych i nigdy nie przechowywać rzeczy, ale nie mam nic przeciwko użyciu narzędzia robi zarówno :-)

Rozwiązaniem, które rozważam jest dodanie c adnotacje ustom w mojej pojo (wersja + nazwa) i stworzyć generator kodu, który wygeneruje JSON/XML na podstawie mojego pojo na podstawie numeru wersji. Chociaż tutaj czuję się, jakbym ponownie wynalazł koło.

Edit: Oto przykład zmian, które mogą być wykonane z wersji 1 do wersji 1.1:

Wersja 1: Osoba Imię lastname

Wersja 1.1 Osoba Imię lastname data urodzenia

Jeśli uzyskasz dostęp do interfejsu API w wersji 1.0, nie otrzymasz atrybutu daty urodzenia - jest to dostępne tylko w wersji 1.1. Chcę obsługi narzędzi do udostępniania tych usług, gdzie mogę skonfigurować, że moje moje pojo (które jest obecnie jak wersja 1.1), chcę udostępnić wersję 1.0, która nie wyświetla tych wartości.

Inne zmiany prawne w modelu mogą polegać na usunięciu atrybutu lub zmianie nazwy atrybutu (lub nawet zmianie nazwy podmiotu).

Edytuj 2: Joel wspomniał w komentarzu, że do dyskusji na temat wersjonowania API powinieneś przeczytać https://stackoverflow.com/posts/9789756/.

Łatwe wyjście z wersjonowania nie oznacza cofania zmian w API, ale zmienia biznes, więc nie zawsze jest to możliwe. Interesuje mnie jak uprościć te zmiany, dlatego moje pytanie.

Edytuj 3: Szukałem narzędzi, które mogłyby pomóc w procesie, ale wciąż nic, co łączy to w dobry sposób z resztą. Oto linki, które znalazłem do tej pory:

• http://wiki.pmease.com/display/xmt/What%27s+XMT (Wygląda jak biblioteki za pomoc POJOs serializacji XML z wersjami)

Answer 1

Jak wspomniano w jednej odpowiedzi, mogą nie być dostępne żadne narzędzia do automatycznego porównywania interfejsów API.

możemy sprostać temu wyzwaniu z podejściem dwuetapowym:

1) Wersjonowanie informacji API Istnieje wiele dyskusji na temat najlepszych praktyk. dwa najbardziej popularne są:

(i) URI redesign - putting version info in URI like 
http://something.com/v1.0/resource1/ or 
http://something.com/resource1?ver=1.0 

(ii) Using HTTP Header - putting version info in Accept/Content-Type 
header keeping URI intact like 
# 
GET /something/ HTTP/1.1 
Accept: application/resource1-v1.0+json 

2) Różne wersje tej samej POJO wykorzystujące json/xml bibliotekę

Po informacji wersja jest z nami mamy do generowania zasobów odpowiednio. Istnieje wiele bibliotek json i xml, dzięki którym możemy zachować wiele wersji tego samego programu i serializować tylko wymagane atrybuty na podstawie wersji. Biblioteka Google gson java działa świetnie. Sprawdzić https://sites.google.com/site/gson/gson-user-guide#TOC-Versioning-Support

public class Person{ 

@Since(1.0) 
private String firstname; 

@Since(1.0) 
private String lastname; 

@Since(1.1) 
private String birthdate; 

} 

Answer 2

Mówisz o czymś, co się dzieje na wersji tego dla jesteś w świecie programowania (utrzymujesz wersje swojego API do przekazywania użytkownikom) lub w świecie serwerów na żywo (negocjowanie treści w czasie wykonywania)?

Dla tych pierwszych, zobacz narzędzia takie jak maven, bluszcz, gradle .. po to są. Osobiście używam programu maven, ponieważ jest to ten, który znam najlepiej, ale wszystkie pozwalają na publikowanie plików jar z wersjami tylko w tym celu.

Answer 3

tylko jedna myśl, ale czy nie byłoby przyjemniej zrobić z nią kompatybilność wsteczną; potrzebujesz tylko wersji dla repozytorium kodu, a to znacznie mniej kłopotów?

Answer 4

Nie znam żadnych narzędzi do automatycznej wersji Twojego RESTful API. W celu przeprowadzenia wielkiej dyskusji na temat RESTU dla wersjonowania powinieneś przeczytać Best practices for API versioning?.

Spędziłem sporo czasu, analizując to, planując RESTful API, i doszliśmy do wniosku, że będziemy ewoluować w sposób, który nie wprowadza przełomowych zmian. Jeśli wymagana jest zmiana zerwania, ujawnilibyśmy ją jako nowy zasób, zamiast próbować użyć informacji o wersji w niestandardowym nagłówku lub typie MIME. Ale, na twoje pytanie, oznacza to pracę po mojej stronie, która jest jeszcze bardziej motywująca do powstrzymania się od dokonywania przełomowych zmian.

Jeśli chodzi o narzędzia, poważnie wątpię, że znajdziesz coś, co może automagicznie wprowadzić zmiany wymagane do obsługi wielu wersji Twojego RESTful API. Wymagałoby narzędzia rozpoznającego różnice między 2 wersjami modelu i wszystkimi interakcjami w interfejsie API.

Jeśli spełniasz zasadę HATEOAS REST, wtedy wszystkie miejsca docelowe z danej lokalizacji są również uwzględniane w odpowiedzi, w takim przypadku możesz użyć czegoś takiego jak REST, aby obsłużyć odwzorowania żądań w Spring MVC, aby zachować numer wersji we wszystkich adresach URL podanych pojedynczego punktu wejścia od klienta, ale nadal trzeba byłoby zachować kontrolery i model dla każdej wersji.

Answer 5

To nie jest odpowiedź można oczekiwać, ponieważ nie używać otwartego narzędzia zewnętrznego źródła zrobić podnoszenia ciężkich dla mnie. Używam własnego narzędzia.

Używam Jersey. Używam/vx/uwzględnione w moich deklaracjach @Path.

Ponieważ REST apis reprezentują kontrakty, nie mam zaufania do automatycznego tworzenia. Jednak zrobiłem narzędzie XLST w niezbyt skomplikowanej wtyczce.) Zachowuję zwięzłą wersję xml i przekształcam ją w klasę gensrc.

Stwierdziłem, że v1 ma określoną ścieżkę i parametry macierzy/zapytania unikalne dla projektu w tym czasie. Kiedy tworzę v2, często stwierdzam, że potrzebuję obsługiwać dodatkowe parametry lub restrukturyzować moje adresy URL w celu lepszego zrozumienia. Po prostu muszę zmienić plik xml.

Generacja mojego generatora stworzy warstwę mojego Jersey z MyAPIv1.java i MyAPIv2.java oraz adnotacją zgodnie z potrzebą czasu.

Tak więc chcę zachować kontrolę nad wersją i posiadanie narzędzia/narzędzia może być szkodliwe.

Ponownie, użycie specyfikacji jest doskonałym sposobem na pełną kontrolę, ale nie w pełni wdraża cienkie warstwy.

Nie ma tu cygara, ale może być pomocne.