Nikt w społeczności REST nie mówi, że REST jest łatwy. HATEOAS to tylko jeden z aspektów, który zwiększa trudności w architekturze REST.
Ludzie nie robią HATEOAS z wszystkich powodów, które sugerujesz: to trudne. Zwiększa złożoność zarówno po stronie serwera, jak i klienta (jeśli faktycznie chcesz z tego skorzystać).
JEDNAK miliardy ludzi doświadczają dziś korzyści z REST. Czy wiesz, jaki jest adres URL „kasy” w Amazon? Ja nie. Jednak mogę codziennie płacić. Czy ten adres URL się zmienił? Nie wiem, nie obchodzi mnie to.
Czy wiesz, że to obchodzi? Każdy, kto napisał screen, zeskrobał automatycznego klienta Amazon. Ktoś, kto prawdopodobnie starannie węszył ruch w sieci, czytał strony HTML itp., Aby dowiedzieć się, jakie linki wywołać, kiedy i za pomocą jakich ładunków.
Gdy tylko Amazon zmienił swoje wewnętrzne procesy i strukturę adresów URL, ci zakodowani klienci zawiedli - ponieważ zepsuły się linki.
Jednak zwykli internauci byli w stanie robić zakupy przez cały dzień bez problemu.
To REST w akcji, jest po prostu wspomagany przez człowieka, który jest w stanie zinterpretować i intuicyjnie interfejs oparty na tekście, rozpoznać małą grafikę z koszykiem i dowiedzieć się, co to właściwie oznacza.
Większość ludzi piszących oprogramowanie tego nie robi. Większość ludzi piszących zautomatyzowanych klientów nie obchodzi. Większość ludzi uważa, że łatwiej jest naprawić swoich klientów, gdy się psują, niż zaprojektować aplikację, aby w ogóle się nie zepsuła. Większość ludzi po prostu nie ma wystarczającej liczby klientów tam, gdzie ma to znaczenie.
Jeśli piszesz wewnętrzny interfejs API do komunikacji między dwoma systemami ze wsparciem technicznym ekspertów i IT po obu stronach ruchu, którzy są w stanie szybko, niezawodnie i zgodnie z harmonogramem zmian komunikować zmiany, to REST nic nie kupuje. Nie potrzebujesz tego, Twoja aplikacja nie jest wystarczająco duża i nie jest wystarczająco długa, aby mieć znaczenie.
Problem ten występuje w dużych witrynach z dużymi bazami użytkowników. Nie mogą po prostu prosić ludzi o zmianę kodu klienta dla kaprysu podczas interakcji z ich systemami. Harmonogram rozwoju serwerów różni się od harmonogramu rozwoju klienta. Nagłe zmiany w API są po prostu nie do przyjęcia dla wszystkich zaangażowanych, ponieważ zakłócają ruch i operacje po obu stronach.
Tak więc taka operacja najprawdopodobniej skorzystałaby na HATEOAS, ponieważ jest łatwiejsza do wersji, łatwiejsza migracja starszych klientów, łatwiejsza kompatybilność wsteczna niż nie.
Klient, który deleguje znaczną część swojego przepływu pracy na serwer i działa na podstawie wyników, jest znacznie bardziej odporny na zmiany na serwerze niż klient, który tego nie robi.
Ale większość ludzi nie potrzebuje takiej elastyczności. Piszą kod serwera dla 2 lub 3 działów, to wszystko do użytku wewnętrznego. Jeśli się zepsuje, naprawiają to i uwzględnili to w swoich normalnych operacjach.
Elastyczność, czy to z REST, czy czegokolwiek innego, rodzi złożoność. Jeśli chcesz, żeby było proste i szybkie, nie robisz tego elastycznym, po prostu zrób to i gotowe. W miarę dodawania abstrakcji i dereferencji do systemów, sprawy stają się trudniejsze, bardziej skomplikowane, więcej kodu do przetestowania.
Znaczna część REST zawodzi w podpunkcie „nie będziesz go potrzebować”. Dopóki, oczywiście, nie zrobisz.
Jeśli potrzebujesz, użyj go i używaj zgodnie z układem. REST nie przepycha rzeczy tam iz powrotem przez HTTP. To nigdy nie było, to znacznie wyższy poziom.
Ale kiedy potrzebujesz RESTU i używasz REST, wtedy HATEOAS jest koniecznością. To część pakietu i klucz do tego, co sprawia, że w ogóle działa.