Usługa API MVC i RESTful

MVC jest dość proste. Istnieje model, kontroler i widok. Kiedy tworzymy stronę internetową, wszystko się łączy, gdy „ klient wysyła żądanie słowa kluczowego REST do serwera -> serwer dopasowuje żądany adres URL do działania kontrolera -> który następnie wywołuje model (y) do gromadzenia / przetwarzania danych, uzyskuje wynik -> i zwraca wynik z powrotem do klienta jako stronę HTML (widok) ”.

Co jeśli mówimy o czystej usłudze sieciowej RESTful API? Następnie przepływ z czymś w rodzaju „ klient wysyła żądanie słowa kluczowego REST do serwera -> serwer dopasowuje żądany adres URL do działania kontrolera -> który następnie wywołuje model (y) do gromadzenia / przetwarzania danych, uzyskuje wynik -> i zwraca wynik z powrotem do klienta w JSON '. Tak jak poprzednio, ale nie ma „widoku” ... a raczej wygenerowany JSON można traktować jako „widok”. W pewnym sensie korzystamy tylko z części MC MVC. Czy tak należy to zrobić? A może istnieją inne, lepiej dopasowane wzorce dla usługi tylko API zamiast MVC?

MVC to paradygmat ze świata Smalltalk, który dotyczy tego, w jaki sposób systemy zorientowane obiektowo mogą mieć interfejsy użytkownika.

Wczesne frameworki internetowe przyjęły ogólną ideę (oddzielają logikę biznesową, logikę kontrolującą i logikę widokową) i stosują tę zasadę do struktury aplikacji. Wcześniej nie było rzadkością, że Bóg strasznie bałagan kodu generowania HTML wewnątrz obiektów domeny lub logiki biznesowej w szablonach HTML (pomyśl bardzo wcześnie PHP)

Chodzi o to, że oryginalny MVC ze świata Smalltalk nie jest tak naprawdę MVC w większości platform internetowych. Wyjście HTML nie jest tak naprawdę „widokiem” w tym sensie, że Smalltalk rozumiał ekran interfejsu użytkownika.

Jest to więc pierwszy powód, dla którego nie należy się odrywać od tego, czy prawidłowo śledzisz MVC. Prawie nic nie jest. Traktuj to mniej jako ścisły podział, a raczej wytyczną Hej, nie byłoby miło, gdyby nasze szablony HTML nie były pełne logiki biznesowej.

Po drugie, MVC jest tylko sposobem na uporządkowanie kodu po stronie serwera. To naprawdę nie ma nic wspólnego z REST / HTTP. REST dotyczy sposobu komunikacji klientów i serwerów. Nie ma znaczenia, czy reprezentacja, którą serwer wysyła do klienta, znajduje się w szablonie HTML, którego budowa wymagała dużo czasu za pomocą silnika szablonów, czy w obiekcie JSON, który był jednym wywołaniem w kontrolerze.

Jeśli nie uważasz, że Twój serwer potrzebuje warstwy „widoku”, która jest w porządku. Nadal będziesz czerpać korzyści z oddzielenia logiki biznesowej (tj. Modelu) od kontrolerów, które obsługują określone żądanie HTTP, nawet jeśli cały kontroler wywołuje wywołanie parsowania JSON dla jakiegoś obiektu i zwraca te dane.

Widok to warstwa odpowiedzialna za wyświetlanie informacji, które mogą być interpretowane przez użytkownika / klienta twojej aplikacji (nie oznacza to, że użytkownik musi być faktyczną osobą). JSON jest całkowicie poprawnym formatem warstwy widoku, komputery to rozumieją.

Tak długo, jak warstwa widoku publikuje informacje, które mogą być wykorzystane przez użytkownika do wpływania na modele w aplikacji, nie ma znaczenia, jak wygląda widok, nadal jest widokiem, warstwą działającą jako oprogramowanie pośrednie między użytkownikiem a systemem .

MVC jest dość proste.

Być może Martin Fowler nie zgodziłby się z tym :

Różni ludzie czytający o MVC w różnych miejscach biorą z niego różne pomysły i opisują je jako „MVC”.

Iść dalej...

Kiedy tworzymy stronę internetową, wszystko się łączy, gdy „klient wysyła żądanie słowa kluczowego REST do serwera -> serwer dopasowuje żądany adres URL do działania kontrolera -> który następnie wywołuje model (y) do gromadzenia / przetwarzania danych, uzyskuje wynik -> i zwraca wynik z powrotem do klienta jako stronę HTML (widok) ”.

OK, to trochę plątanina

MVC, cokolwiek to jest, to zbiór pomysłów na implementację interfejsów użytkownika.

REST to zbiór ograniczeń architektonicznych do tworzenia aplikacji na dużą skalę.

Internet, o którym tu mówisz, to gigantyczna aplikacja do zarządzania dokumentami zbudowana przy użyciu większości tych samych ograniczeń.

Podobieństwa, które widzisz między nimi, są (wybierz) niepoprawnie przypisane lub powierzchowne.

RESTafarianie mają wspólne rozumienie HATEOAS , „hipertekstu jako silnika stanu aplikacji”, i to powinno wysyłać alarmy dzwoniące przez twoją głowę - dlaczego widok miałby być silnikiem stanu ? Jeśli kwestionujemy tę przesłankę i szukamy dodatkowych dowodów, możemy również zauważyć dwie dziwne rzeczy.

Po pierwsze, że możemy całkowicie usunąć serwer HTTP z równania, ładując HTML z dysku. Przeglądarka jest z tego całkowicie zadowolona, ​​usprawiedliwiając niewielkie zmiany w zachowaniu, które mogą wynikać ze zmiany podstawowego adresu URL. Widoki zwykle nie działają, gdy zostały całkowicie odłączone od modelu i kontrolera w ten sposób.

Po drugie, jeśli uważnie obserwujemy nowoczesną przeglądarkę, zauważymy, że istnieje wiele widoków HTML. Wiele widoków widoku wydaje się naprawdę dziwnym pomysłem, ale na pewno jest główna prezentacja z dużą ilością znaczników tekstowych, które reagują na gesty użytkownika, a następnie jest to „Widok źródłowy”, który pokazuje surowy HTML, a także reaguje na gesty użytkownika. Żółwie do samego końca!

Odpowiedzią na zagadkę jest oczywiście to, że HTML nie jest widokiem. Zbiór widżetów w przeglądarce to widok, który komunikuje się z Document Object Model , który został zainicjowany przez odczyt HTML.

Innymi słowy, HTML jest reprezentacją stanu, tak jak obiecał Roy T. Fielding .

Co jeśli mówimy o czystej usłudze sieciowej RESTful API ...? Tak jak poprzednio, ale nie ma „widoku”

Bardziej poprawnie, tak jak poprzednio: nie ma widoku. JSON, podobnie jak HTML, jest reprezentacją stanu, odpowiednią do przekraczania granic procesu.

Pomyśl „DTO” lub „Wiadomość”, a twoje wnioski będą o wiele mniej prawdopodobne, by cię sprowadzić na manowce.

Czy tak należy to zrobić?

Przekazywanie JSON jako widoku lub używanie go jako modelu widoku do konstruowania widoku nie narusza wzorca.

Korzystam z tej samej architektury w bieżącej aplikacji, nad którą pracuję i działa bardzo dobrze. Razem z ładnym frameworkiem JS możesz tworzyć naprawdę responsywne projekty.

A może istnieją inne, lepiej dopasowane wzorce dla usługi tylko API zamiast MVC?

Szczerze mówiąc, nie mam pojęcia. Ale myślę, że to, czy używasz MVC, czy nie w API, nie jest tak ważne. Używaj wszystkiego, co uznasz za wygodne. Mówiąc o usługach internetowych, należy wziąć pod uwagę o wiele ważniejsze aspekty (niezwiązane bezpośrednio z MVC), np. Bezpieczeństwo, spójność, dostępność itp.