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

10

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ć?

początkujący_
źródło
2
Jeśli chcesz spędzać więcej czasu z najbliższymi i chcesz mieć czas wolny, aby cieszyć się hobby lub realizować osobiste cele, to na miłość boską: Nie programuj takich aplikacji! Ale jeśli lubisz spóźniać się w nocy i spędzać weekendy w biurze, utrzymując mnóstwo „sprytnego” kodu, wybierz coś dla siebie.
Tulains Córdova
3
Czy potrafisz szczegółowo opracować to, co uważasz za złe? Kontekst: To nie jest bestia 10 Mio LOC, która ma kluczowe znaczenie dla biznesu. To bardziej jak <5000 LOC i nie ma znaczenia, czy nie działa przez kilka dni. Tak, to nie było tak, że powinienem robić gówniane rzeczy, dlatego opracuj to, co uważasz za złe.
beginner_
@begginer_ Każde oprogramowanie zaczyna się od małego. To, co opisujesz, przypomina maszynę Rube Goldberga: młot uderza człowieka, mężczyzna upuszcza herbatniki, chwyta papugi i przechyla wazon itp.
Tulains Córdova
Powodem tego jest często poprawa wydajności, gdzie pobieranie danych może odbywać się za pomocą wielu jednoczesnych żądań do różnych serwerów. Nie wydaje się, aby miało to zastosowanie w twoim przypadku.
user16764,
Jak korzystasz z tej usługi od klientów, takich jak skrypty lub curl? Te rzeczy nie mają interpreterów javascript. Czy dotyczy to usługi tylko przeglądarki?
Bryan Oakley

Odpowiedzi:

17

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.

Jan Hudec
źródło
Piszę grubych klientów w JavaScript, którzy właśnie to robią. Ale to chyba zły pomysł na normalne strony internetowe.
K ..
Dlaczego nie jest to REST?
Dagnelies,
1
Jeśli rozróżnisz „dane” tworzące aplikację (HTML, JS, CSS itp.) I „dane” wyświetlane przez aplikację (JSON), częścią JSON jest REST, ale część ładująca „kod” nie jest t. Jeśli widzisz to wszystko bardziej abstrakcyjnie, oba są.
K ..
2

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.

Steven Schlansker
źródło
2
Apache to przesada w przypadku treści statycznych. Są znacznie szybsze serwery. Najpopularniejszy wydaje się być Nginx .
Jan Hudec
5
To był przykład, nic więcej.
Steven Schlansker
2

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.

Ross Patterson
źródło
1
... i wielki powód, że wiele zrobić, to dlatego, że interakcja danych za pośrednictwem usług / JSON i tak , więc jest to prawdopodobnie lepiej obsłużyć wszystkich interakcji danych w ten sam sposób. (tzn. jeśli używasz AJAX do odświeżania stołu ... powinieneś go również użyć do jego zbudowania.)
Chad Thompson
@ChadThompson Tak, uważam, że dużo czasu, jeśli nie buduję takich rzeczy w pierwszej kolejności, gdzieś w dalszej kolejności otrzymam prośbę o funkcję dynamicznej aktualizacji strony w oparciu o działanie klienta - co oznacza, że ​​prosta implementacja prowadzi teraz zarówno do klienta, jak i do serwera, którzy wiedzą, jak zbudować stronę. Łatwiej jest po prostu zbudować go na kliencie.
Tacroy,
1

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.

Tim Post
źródło
Co rozumiesz przez „random JS”? W moim przypadku to, co opisujesz powyżej, jest o wiele bardziej złożone (kilka pól wejściowych i tabela (slickgrid) lub tabulatory interfejsu użytkownika jquery). To jest to. Około 200 LOC na stronę.
beginner_
0

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.

Broncha
źródło
0

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.

parsifal
źródło
dzięki nigdy nie słyszałem o AngularJS. Ale myślę, że jak na moje obecne potrzeby to za dużo.
beginner_
0

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

Keith Pincombe
źródło