Czy to jest „anty-wzór” i czy powinienem przestać go używać, czy jest to sprytny projekt?

Zasadniczo starałem się wykonać następujące czynności podczas tworzenia usługi REST:

1. Wymagany jest HTML
2. usługa zwraca żądaną stronę internetową, ale bez żądanego „zasobu”, np. dane
3. strona zawiera JavaScript, który wysyła żądanie AJAX do tej samej usługi (inny typ zawartości)
4. Usługa zwraca rzeczywiste dane (JSON), a strona wyświetla je

Z jednej strony wydaje się to nieefektywne (2 żądania), ale gdy go użyłem, „wydajność nie ma znaczenia”, co oznacza, że ​​wewnętrzna aplikacja o niskim natężeniu ruchu i strony internetowe są proste i ładują się szybko.

Powodem tego jest to, że strona internetowa może wtedy być prawie czystym HTML + JavaScript i prawie nie są wymagane żadne elementy po stronie serwera, szczególnie żadnych pętli, do tworzenia tabel i tego typu rzeczy (co moim zdaniem jest bardzo brzydkie w porównaniu do rzeczy takie jak slickgrid), np. separacja danych i widoku.

Czy zanim zacznę z tego korzystać, to dobry pomysł, czy powinienem po prostu przestać to robić?

Jeśli zażądasz zasobu, który nie zawiera danych, oznacza to, że nie jest to usługa REST. Usługa dostarczająca rzeczywiste dane w Json może być, ale część HTML nie. W przypadku aplikacji internetowej nie ma to znaczenia.

Technika działa, ale musisz zdawać sobie sprawę z jej ograniczeń:

1. Wyszukiwarki nie interpretują JavaScript, więc strona zaimplementowana w ten sposób nie będzie indeksowana przez Google i podobne. W przypadku zastosowania wewnętrznego nie ma to znaczenia, w przypadku publicznego miałoby to duże znaczenie.
2. Użytkownicy ze specjalnymi potrzebami (np. Używający terminali brajlowskich) korzystają ze specjalnych przeglądarek, które są raczej ograniczone i mogą nie interpretować poprawnie JavaScript.

Chciałbym również zauważyć, że kod generujący HTML jest w zasadzie taki sam, niezależnie od tego, czy działa po stronie serwera, czy po stronie klienta. Masz znacznie większy wybór zarówno języków, jak i frameworków po stronie serwera i jestem pewien, że istnieje kilka odpowiedników slickgrid.

Możesz i powinieneś nadal utrzymywać separację danych i wyświetlania po stronie serwera. System szablonów może i powinien po prostu traktować dane jako strukturę danych, a nawet json (zwłaszcza jeśli rzeczywista usługa jest w innym języku niż system szablonów) i po prostu rozszerzać szablon o te dane.

I nie, nie myślę o PHP; jest to najmniej zdolny system szablonów (choć istnieją na nim lepsze). Mam na myśli Genshi lub XSLT lub coś jeszcze bardziej zaawansowany, że zapewnia widgetów internetowych.

Nie ma w tym nic złego, o ile upewnisz się, że kod jest uporządkowany w przejrzysty sposób. Możesz nawet podawać zawartość statyczną np. Z Apache, a nie z serwisu internetowego.

To dobra praktyka. I dzieje się to cały czas, jak wskazuje @JHHudec, nazywanie go usługą REST jest błędne. Ale wiele stron internetowych robi to dokładnie z dokładnie wymienionych powodów.

Nie nazwałbym tego anty-wzorcem, to, co opisujesz, jest mniej więcej grubym klientem , a nie zupełnie inaczej niż usługi takie jak Trello. Początkową odpowiedzialnością serwera jest wysłanie DOM i wszelkich zasobów niezbędnych do działania klienta. Pracowałem nad podobnymi projektami w zakresie automatyzacji centrów danych i monitorowania sieci.

Klient zaczyna jako rzadki DOM, pobiera niektóre dane za pośrednictwem XHR (czasami przez JSONP) i ostatecznie przyłącza się do serwera gniazd. Jeszcze bardziej podstawowym przykładem może być aplikacja do czatowania.

Jedynym powodem, dla którego nie należy tego robić, jest to, że naprawienie problemu może być bardzo trudne. Jeśli czujesz się komfortowo z asynchronicznym programowaniem funkcjonalnym i wszystkimi wyścigami oraz innymi wyzwaniami, które może on stwarzać, nie będziesz miał problemu z utrzymaniem go. Co ważniejsze, nie będziesz mieć problemu z napisaniem go, aby inni ludzie mogli go w końcu utrzymać.

Jeśli myśl o dodaniu kolejnych funkcji zaczyna Cię przerażać lub odkryjesz, że debugowanie to koszmar, możesz rozważyć inne metody produkcji, kontynuując eksperymentowanie i naukę.

Jest to prawidłowy projekt, o ile nie wykopujesz dla siebie dziury. Jeśli masz plotki i plotki losowego JS wszędzie zamiast czystego interfejsu, prawdopodobnie prawdopodobnie chcesz zmienić fakturę lub zająć się projektem w inny sposób. Większość funkcji, które mają być uruchamiane po załadowaniu wszystkich zasobów, powinny być anonimowe i wprowadzone z czystego interfejsu. Jeśli nie są, możesz mieć kłopoty.

jak powiedział Jan Hudec, twoje podejście zdecydowanie nie może być nazwane REST. Chociaż może to być część, w której klient żąda zasobu. Lepiej jest, jeśli klient obsługuje część prezentacji, podobnie jak backbonerobi. Komunikuje się z serwerem REST dla zasobów i wyświetla je za pomocą views.

Może to być anty-wzorzec, ale myślę, że to także przyszłość aplikacji internetowych. Jednak zamiast bawić się JavaScriptem, powinieneś używać przynajmniej biblioteki szablonów. Lepszym rozwiązaniem jest framework MVC po stronie klienta, taki jak AngularJS (którego obecnie używam).

Aby uzyskać więcej referencji, oto popularny post na blogu porównujący kilka platform, a tutaj jest witryna, która implementuje ten sam program przy użyciu wielu platform.

Również: komentarze Jana Hudeca dotyczące interakcji wyszukiwarek i czytników ekranu są poprawne. Jeśli pracujesz nad witryną eCommerce (gdzie liczy się PageRank), prawdopodobnie nie chcesz używać ram po stronie klienta. Ale w przypadku aplikacji wewnętrznych zwykle nie są to obawy.

Co robisz, brzmi dobrze! Jeśli jednak twoje odpowiedzi JSON zawierają HTML, to marnujesz czas.

Inną kwestią jest to, że twój głupi klient powinien prawdopodobnie pobierać swoje dane JSON z innego projektu. Powinieneś dążyć do właściwego oddzielenia klienta od usługi, wtedy będziesz mieć odpowiednią usługę RESTful