co to jest hipermedia, kontrola hipermedia, formaty hipermediów

Question

Obecnie czytam książkę "Odpoczynek w praktyce". Nie rozumiem następującej terminologii: hipermedia, format hipermedialny, kontrola hipermedia, protokół aplikacji domeny. Autor sugeruje potrzebę formatu hipermediów specyficznych dla domeny. Nie mogłem tego zrozumieć. Przeszukałem te hasła, ale nie mogłem znaleźć właściwej odpowiedzi. Czy ktoś może wyjaśnić te terminy i dlaczego potrzebujemy formatów hipermedialnych specyficznych dla domeny zamiast aplikacji/xml?

Answer 1

Hipermedia = fakt, że klient i serwer rozmawiają w kategoriach jednolitej reprezentacji, np. Hiperłącza.

---

HyperMedia Control = Zasób musi być wykonany na nim. Na przykład produkt jest reprezentowany przez domenę/produkt hiperłącza/001 , a następnie zasoby mogą być obsługiwane (edytowane i usuwane) w domenie kontrolnej hypermedia/product/001/edit i domenie/product/001/delete.

---

Największa różnica w podejściu. Systemy proceduralne najpierw zapisują operacje jako przejścia stanu w kodzie sekwencyjnym (Java, itd.), a następnie interakcje są wytwarzane jako hiperlinki w celu dostarczenia HATEOAS.

Ale systemy są traktowane jako interakcje bezpośrednio modelują interakcje, a zatem bezpośrednio przekazują hiperłącza. Przykładowy przykład to http://www.masterkube.com/hateoas_technology.html.

Mam nadzieję, że to pomoże.

Answer 2

Jest w tym sporo zamieszania, ponieważ większość aplikacji, które nazywają się REST, nie używa hipermedii i wcale nie jest WYPOCZYNKOWAĆ.

Hypermedia to uogólnienie hipertekstu dla treści innych niż HTML. Można powiedzieć, że hipertekst jest podzbiorem hipermedii. Hypermedia może być HTML w przeglądarce, z wszystkimi linkami, przyciskami i wszystkim, co jest renderowane, abyś mógł przeglądać stronę internetową, lub może to być dokument XML lub JSON, który ma być analizowany przez automatycznego klienta, który będzie również śledził łącza i działania, takie jak człowiek zrobiłby to z przeglądarką, klikając wyrenderowane łącza i przyciski.

hateoas oznacza, że ​​interakcja z klientem z aplikacji reszta musi być napędzany przez hipermediów, lub mówiąc po prostu, klient powinien otrzymać wszystkie URI dla każdego zasobu potrzebuje wykonując linki w reprezentacji samych zasobów, nie polegając na informacjach pozapasmowych, takich jak wzorce URI podane w dokumentacji, jak wiele API.

To jest prostsze niż się wydaje. Oznacza to tylko, że interakcja między klientem a aplikacją REST powinna być dokładnie taka sama, jak przeglądanie strony przez człowieka. Na przykład: Take Over Overflow. Są użytkownicy, pytania i odpowiedzi. Jeśli chcesz zobaczyć listę pytań, nie wchodź na stronę z dokumentacją, zdobądź szablon URI do wpisywania pytań, wypełnij symbol zastępczy swoim identyfikatorem użytkownika i wklej go do swojego brązownika. Po prostu klikasz łącze do innego dokumentu opisanego jako lista pytań, a nawet nie zależy Ci na tym, jaki jest dokładny adres URI. To właśnie HATEOAS oznacza w praktyce.

Formularz hipermedia t definiuje umowę między klientem a serwerem. Jest to format danych z hiperłączem, którego używasz do reprezentowania zasobów w aplikacji hipermedialnej. Na przykład, jeśli masz zasób użytkownika, musisz udokumentować, czego dokładnie klienci oczekują od reprezentacji tego zasobu i jak przeanalizować reprezentację, aby wyodrębnić informacje. Przed rozpoczęciem interakcji z interfejsem API klienci muszą zaimplementować analizator składni, aby wyodrębnić informacje, muszą wiedzieć, jakie właściwości ma zasób i co oznaczają, jakie relacje łącza powinny oczekiwać i jakie przejścia stanu są dostępne, itp.

Sterowanie hipermedia to kombinacje metod protokołów i relacji między linkami w formacie hipermedialnym, które informują klienta, jakie przejścia między stanami są dostępne i jak je wykonać. Na przykład pytanie może mieć link rel=post_answer, który oczekuje reprezentacji odpowiedzi jako ładunku metody POST i utworzy nowy zasób odpowiedzi związany z tym pytaniem.

Po zdefiniowaniu zestawu formatów hipermedialnych wymagany jest typ specyficzny dla domeny typ nośnika w celu określenia, jaki format hipermedii jest używany w konkretnej interakcji. Typowy typ nośnika, taki jak application/xml, mówi klientowi tylko, jak przeanalizować format danych, nie mówi nic o informacjach wyodrębnionych przez analizator składni. Na przykład, powiedzmy, że dokument ma nośnik typu application/vnd.mycompany.user.v1+xml, klient wie, że jest to wersja 1.0 zasobu użytkownika w formacie XML.Jeśli zmienisz zasób, dodając lub usuwając właściwości, linki itp., Możesz zmienić numer wersji, a klienci nie zostaną złamani, ponieważ mogą zażądać wersji, dla której zostały zaimplementowane, używając nagłówka Accept. Można również zapewnić wiele formatów dla tego samego zasobu, takich jak XML lub JSON, a nawet całkiem czytelne dla człowieka przedstawienie w HTML.

Po zawinięciu wszystkiego razem - podstawowy protokół, HTTP; kontrakty zdefiniowane przez formaty hipermediów i typy mediów - masz swój Domain Application Protocol, który jest całym zbiorem zasobów i dostępnych przejść stanu reklamowanych przez twoją aplikację.

Nie trzeba dodawać, że 99% tak zwanych interfejsów REST API dostępnych w Internecie nie spełnia tych wszystkich wymagań. Większość z nich to po prostu interfejsy API HTTP, które są zgodne z niektórymi ograniczeniami REST, czasami dlatego, że tak naprawdę nie potrzebują wszystkich z nich, czasami dlatego, że deweloperzy uważali, że REST naprawdę jest.