Co właściwie jest nie tak z punktem końcowym zwracającym HTML, a nie danymi JSON?

Kiedy zacząłem uczyć się PHP (około 5 lub 6 lat temu), dowiedziałem się o Ajaxie i przeszedłem „fazy”:

1. Serwer zwraca dane w formacie HTML i umieścić go wewnątrz Doma innerHTML
2. Dowiesz się o formatach przesyłania danych, takich jak XML (i powiesz „oooh, więc to jest to, do czego służy), a następnie JSON.
3. Zwracasz JSON i budujesz swój interfejs użytkownika za pomocą waniliowego kodu JavaScript
4. Przechodzisz do jQuery
5. Dowiesz się o interfejsach API, nagłówkach, kodach stanu HTTP, REST , CORS i Bootstrap
6. Uczysz się SPA i frameworków frontendowych ( React , Vue.js i AngularJS ) oraz standardu JSON API.
7. Otrzymujesz trochę starszego kodu przedsiębiorstwa i po jego sprawdzeniu okazuje się, że robi to, co opisano w kroku 1.

Ponieważ pracowałem z tą starszą bazą kodu, nawet nie pomyślałem, że może ona zwrócić HTML (to znaczy, jesteśmy teraz profesjonalistami, prawda?), Więc trudno mi było znaleźć punkt końcowy JSON, który zwraca dane, które wywołania Ajax wypełniają się. Dopiero zapytałem „programistę”, że powiedział mi, że zwraca HTML i jest dołączany bezpośrednio do DOM za pomocą innerHTML.

Oczywiście trudno było to zaakceptować. Zacząłem myśleć o sposobach przefaktoryzowania tego do punktów końcowych JSON, zastanawiając się nad jednostkowym testowaniem punktów końcowych i tak dalej. Jednak ta baza kodu nie ma żadnych testów. Ani jednego. I to ponad 200 000 linii. Oczywiście jednym z moich zadań jest zaproponowanie podejścia do przetestowania całości, ale w tej chwili jeszcze się tym nie zajmujemy.

Więc nigdzie się nie zastanawiam: jeśli nie mamy żadnych testów, więc nie mamy szczególnego powodu, aby utworzyć ten punkt końcowy JSON (ponieważ nie jest to „wielokrotnego użytku”: dosłownie zwraca dane, które pasują tylko w tej części aplikacji, ale myślę, że to już sugerowano, ponieważ ... zwraca dane HTML).

Co dokładnie jest złego w robieniu tego?

Co właściwie jest nie tak z punktem końcowym zwracającym HTML, a nie danymi JSON?

Nic takiego. Każda aplikacja ma inne wymagania i być może aplikacja nie została zaprojektowana jako SPA.

Być może te piękne ramy, które zacytowałeś (Angular, Vue, React itp.), Nie były dostępne w czasie programowania lub nie były „zatwierdzonymi” przedsiębiorczymi rzeczami do wykorzystania w Twojej organizacji.

Powiem ci to: punkt końcowy, który zwraca HTML, zmniejsza twoją zależność od bibliotek JavaScript i zmniejsza obciążenie przeglądarki użytkownika, ponieważ nie będzie musiał interpretować / wykonywać kodu JS, aby tworzyć obiekty DOM - HTML już tam jest, to tylko kwestia parsowania elementów i renderowania ich. Oczywiście oznacza to, że mówimy o rozsądnej ilości danych. 10 megabajtów danych HTML nie jest rozsądne.

Ale ponieważ nie ma nic złego w zwracaniu HTML, to, co tracisz, nie używając JSON / XML, to w zasadzie możliwość użycia twojego punktu końcowego jako API. I oto najważniejsze pytanie: czy naprawdę musi to być interfejs API?

Powiązane: Czy można zwracać HTML z JSON API?

JSON i HTML spełniają dwa różne cele semantyczne.

Jeśli wypełniasz stronę internetową danymi, użyj JSON. Jeśli tworzysz stronę internetową z części stron, użyj HTML.

Mogą brzmieć jakby były tym samym, ale wcale nie są. Po pierwsze, gdy budujesz część strony przy użyciu HTML zwróconego przez serwer, pracujesz po stronie serwera. Gdy wiążesz dane ze stroną internetową, pracujesz po stronie klienta.

Musisz też uważać na HTML, aby nie ściśle powiązać z określoną stroną. Cały sens renderowania stron częściowych w ten sposób polega na tym , że częściowe mogą być ponownie użyte, a jeśli uczynisz częściową zbyt szczegółową, nie będzie komponować się z innymi stronami. JSON nie ma tego problemu, ponieważ to tylko dane, a nie struktura strony internetowej.

Głównym problemem jest to, że ściśle łączy serwer z klientem, który musi znać strukturę HTML. Utrudnia także ponowne użycie punktów końcowych na nowe sposoby lub nowe aplikacje.

Zwracanie zwykłych danych i pozwalanie klientowi na ich renderowanie zmniejsza sprzężenie oraz zwiększa elastyczność i testowalność - możesz uruchomić testy jednostkowe na kliencie dla próbnych danych i uruchomić testy jednostkowe na serwerze, aby przetestować pożądane dane.

Myślę, że masz to trochę wstecz. Mówisz:

nie mamy żadnego testu, więc nie mamy konkretnego powodu, aby utworzyć ten punkt końcowy JSON

Powodem stosowanie odpowiedniej końcowy będzie tak, że mógł go przetestować. Powiedziałbym, że brak testów to bardzo dobry powód, aby zacząć pisać. To znaczy, jeśli istnieje jakakolwiek logika, która byłaby odpowiednia do przetestowania.

200 000 wierszy kodu to dużo do refaktoryzacji i prawdopodobnie trudno je utrzymać. Wyrwanie niektórych punktów końcowych i przetestowanie ich może być dobrym miejscem na rozpoczęcie.

Innym powodem może być oddzielenie serwera od klienta. Jeśli w odległej przyszłości zmieni się projekt lub układ aplikacji, łatwiej jest pracować z odpowiednim formatem danych niż z danymi wyjściowymi HTML. W idealnym świecie wystarczy tylko zmienić klienta i w ogóle nie dotykać serwera.

Istnieją 3 sposoby (przynajmniej?) Na utworzenie strony internetowej:

• Wygeneruj całą stronę serwera strony.
• Zwróć stronę z odkrytymi kośćmi z serwera plus kod (JavaScript) i poproś stronę o pobranie danych i renderowanie w kliencie HTML.
• Zwróć częściową stronę plus kod i poproś kod o pobranie wstępnie renderowanych bloków HTML, które można upuścić na stronę.

Pierwszy jest w porządku. Drugi też jest w porządku. To ostatni problem.

Powód jest prosty: teraz podzieliłeś budowę strony HTML na całkowicie odłączone części. Problem polega na konserwacji. Teraz masz dwa oddzielne podmioty odpowiedzialne za zarządzanie szczegółami interfejsu użytkownika. Musisz więc synchronizować CSS i inne podobne szczegóły między dwoma oddzielnymi elementami. Zmieniłeś szerokość paska bocznego? Wspaniały. Teraz fragment HTML, który powraca, powoduje przewijanie w poziomie, ponieważ jego założenia dotyczące szerokości paska bocznego już się nie utrzymują. Zmieniłeś kolor tła dla tego bloku? Świetnie, teraz kolor czcionki fragmentu HTML koliduje, ponieważ przybierał inny kolor tła i ktoś zapomniał przetestować ten punkt końcowy.

Chodzi o to, że podzieliłeś teraz wiedzę, która powinna być scentralizowana w jednym miejscu (a mianowicie logika prezentacji), a to utrudnia upewnienie się, że wszystkie elementy pasują do siebie poprawnie. Korzystając z interfejsu API JSON, możesz zamiast tego zachować całą logikę tylko w interfejsie lub możesz zachować wszystko w szablonach po stronie serwera, jeśli na początku renderujesz dane w formacie HTML. Chodzi o utrzymanie wiedzy / logiki prezentacji w jednym miejscu, aby można było nią zarządzać konsekwentnie i jako część jednego procesu. HTML / CSS / JS jest wystarczająco trudny do utrzymania prosto, bez rozbijania go na wiele małych kawałków.

Interfejsy API JSON mają również tę dodatkową zaletę, że udostępniają dane całkowicie niezależnie od logiki prezentacji. Dzięki temu wielu różnych prezenterów, takich jak aplikacja mobilna i strona internetowa, może korzystać z tych samych danych. W szczególności umożliwia korzystanie z danych bez przeglądarki (takich jak aplikacje mobilne lub nocne zadania cron); ci konsumenci mogą nawet nie być w stanie przeanalizować HTML. (To oczywiście musi zależeć od sytuacji, w której dane są takie same między różnymi konsumentami lub można użyć podzbioru drugiego.) To, czy potrzebujesz tej zdolności, zależy jednak od wymagań konkretnej aplikacji podczas zarządzania prezentacją logika jest konieczna niezależnie. Powiem, że jeśli wdrożysz go z góry, będziesz lepiej przygotowany na przyszły rozwój.

Powiedziałbym, że nie ma nic złego w tym, że serwer zwraca fragment HTML i interfejs użytkownika przypisuje go do .innerHTML jakiegoś elementu. Jest to, moim zdaniem, najprostszy sposób na opracowanie asynchronicznego kodu JavaScript. Zaletą jest to, że przy użyciu JavaScriptu wykonywana jest jak najmniej czynności, a tak dużo, jak to możliwe, w kontrolowanym środowisku zaplecza. Pamiętaj, że obsługa JavaScript w przeglądarkach jest różna, ale twój back-end ma zawsze tę samą wersję komponentów back-end, co oznacza, że ​​zrobienie jak najwięcej w back-endie będzie oznaczało jak najmniej niezgodności wersji.

Czasami chcesz czegoś więcej niż tylko fragment HTML. Na przykład kod stanu i fragment HTML. Następnie możesz użyć obiektu JSON, który ma dwa elementy, statusCode i HTML, z których drugi można przypisać do .innerHTML jakiegoś elementu po sprawdzeniu statusCode. Tak więc używanie JSON i wewnętrznaHTML nie są w żadnym wypadku alternatywnymi podejściami wyłącznymi; mogą być używane razem.

Używając JSON, możesz nawet mieć wiele fragmentów HTML w tej samej odpowiedzi, które są przypisywane do .innerHTML wielu elementów.

Podsumowując: użyj .innerHTML. Sprawia, że ​​Twój kod jest kompatybilny z jak największą liczbą wersji przeglądarki. Jeśli potrzebujesz więcej, użyj JSON i .innerHTML razem. Unikaj XML.

Zasadniczo nie ma nic złego . Pytanie brzmi: co chcesz osiągnąć?

JSON jest idealny do przesyłania danych. Jeśli zamiast tego wyślesz HTML i oczekujesz, że klient wyodrębni dane z HTML, to śmieci.

Z drugiej strony, jeśli chcesz przesłać HMTL, który będzie renderowany jako HTML, to wyślij go jako HTML - zamiast pakować HTML w ciąg znaków, zamieniać ciąg w JSON, transmitować JSON, dekodować po drugiej stronie , pobieranie ciągu i wyodrębnianie kodu HTML z ciągu.

I właśnie wczoraj natknąłem się na kod, który umieścił dwa elementy w tablicy, zamieniłem tablicę w JSON, umieściłem JSON w ciągu, włożyłem ciąg do tablicy, zmieniłem całą tablicę w JSON, wysłałem do klienta, który dekodował JSON, wziął tablicę zawierającą łańcuch, wziął łańcuch, wyodrębnił JSON z łańcucha, zdekodował JSON i otrzymał tablicę z dwoma elementami. Nie rób tego

Wszystko zależy od celu interfejsu API, ale ogólnie to, co opisujesz, jest dość silnym naruszeniem separacji obaw :

W nowoczesnej aplikacji kod API powinien odpowiadać za dane, a kod klienta powinien odpowiadać za prezentację.

Gdy interfejs API zwraca HTML, ściśle łączysz swoje dane i prezentację. Gdy interfejs API zwraca HTML, jedyną rzeczą, którą możesz (łatwo) zrobić z tym HTMLem, jest wyświetlenie go jako części większej strony. Z innej perspektywy, jedyną rzeczą, do której API jest dobre, jest dostarczanie twojej stronie HTML. Ponadto rozłożyłeś swój HTML na kod klienta i serwer. Może to sprawić, że utrzymanie stanie się problemem.

Jeśli interfejs API zwraca JSON lub inną formę czystych danych, staje się znacznie bardziej użyteczny. Istniejąca aplikacja może nadal wykorzystywać te dane i odpowiednio je prezentować. Teraz jednak inne rzeczy mogą korzystać z interfejsu API, aby uzyskać dostęp do tych samych danych. Również konserwacja jest łatwiejsza - cały HTML znajduje się w jednym miejscu, więc jeśli chcesz zmienić styl całej witryny, nie musisz zmieniać interfejsu API.

HTML jest powiązany z konkretnym projektem i zastosowaniem.

W przypadku HTML, jeśli chcesz zmienić układ strony, musisz zmienić sposób generowania kodu HTML przez wywołanie serwera. Zwykle wymaga to programisty zaplecza. Teraz masz programistów zaplecza, którzy z definicji nie są najlepszymi pisarzami HTML, obsługującymi te aktualizacje.

W przypadku JSON, jeśli układ strony ulegnie zmianie, istniejące wywołanie serwera JSON niekoniecznie musi się zmienić. Zamiast tego programista front-end, a nawet projektant, aktualizuje szablon, aby wygenerować inny kod HTML z tych samych podstawowych danych.

Ponadto JSON może stać się podstawą dla innych usług. Możesz mieć różne role, które muszą widzieć te same podstawowe dane na różne sposoby. Na przykład możesz mieć witrynę internetową klienta, która pokazuje dane o produkcie na stronie zamówienia, oraz wewnętrzną stronę sprzedaży dla przedstawicieli, która pokazuje te same dane w zupełnie innym układzie, być może obok niektórych innych informacji niedostępnych dla klientów ogólnych. Dzięki JSON w obu widokach można używać tego samego wywołania serwera.

Wreszcie, JSON może skalować się lepiej. W ostatnich latach przesadziliśmy z frameworkami javascript po stronie klienta. Myślę, że nadszedł czas, aby cofnąć się o krok i zacząć myśleć o tym, jakiego javascript używamy i jak wpływa on na wydajność przeglądarki ... szczególnie na urządzeniach mobilnych. To powiedziawszy, jeśli prowadzisz witrynę wystarczająco dużą, aby wymagać farmy serwerów lub klastra, zamiast jednego serwera, JSON może skalować się lepiej. Użytkownicy zapewnią ci czas przetwarzania w swoich przeglądarkach za darmo, a jeśli to wykorzystasz, możesz zmniejszyć obciążenie serwera w dużym wdrożeniu. JSON zużywa również mniejszą przepustowość, więc ponownie, jeśli jesteś wystarczająco dużyi używaj go odpowiednio, JSON jest wymiernie tańszy. Oczywiście może się również skalować gorzej, jeśli skończysz karmieniem bibliotek 40 KB, aby parsować 2 KB danych do 7 KB HTML, więc znowu: opłaca się być świadomym tego, co robisz. Ale JSON ma potencjał, aby poprawić wydajność i koszty.

Nie ma nic złego w takim punkcie końcowym, jeśli spełnia on swoje wymagania. Jeśli wymagane jest wyplucie kodu HTML, który znany konsument może efektywnie przeanalizować, jasne, dlaczego nie?

Problem polega na tym, że w ogólnym przypadku chcesz, aby punkty końcowe wypluły ładunek, który jest dobrze uformowany i skutecznie analizowany przez standardowy analizator składni. I przez efektywne analizowalne, mam na myśli deklaratywne analizowalne.

Jeśli twój klient jest zmuszony odczytać ładunek i podważyć z niego otwarte bity informacji za pomocą pętli i instrukcji if, to nie jest to skutecznie analizowalne. A HTML, tak po swojemu, jest bardzo wybaczony, ponieważ nie wymaga od siebie dobrego tworzenia.

Teraz, jeśli upewnisz się, że Twój HTML jest zgodny z XML, to jesteś złoty.

Powiedziawszy to, mam z tym poważny problem:

Powiem ci to: punkt końcowy, który zwraca HTML, zmniejsza twoją zależność od bibliotek JavaScript i zmniejsza obciążenie przeglądarki użytkownika, ponieważ nie będzie musiał interpretować / wykonywać kodu JS, aby tworzyć obiekty DOM - HTML już tam jest, to tylko kwestia parsowania elementów i renderowania ich. Oczywiście oznacza to, że mówimy o rozsądnej ilości danych. 10 megabajtów danych HTML nie jest rozsądne.

To zły pomysł, bez względu na to, jak go pokroisz. Kilkadziesiąt lat kolektywnego doświadczenia przemysłowego pokazało nam, że ogólnie dobrym pomysłem jest oddzielenie danych (lub modeli) od ich wyświetlania (lub widoku).

Łączymy je tutaj w celu szybkiego wykonania kodu JS. I to jest mikrooptymalizacja.

Nigdy nie uważałem tego za dobry pomysł, z wyjątkiem bardzo trywialnych systemów.

Moja rada? Nie rób tego HC SVNT DRACONES , YMMV itp.

JSON to tylko tekstowa prezentacja uporządkowanych danych. Klient oczywiście musi mieć analizator składni do przetwarzania danych, ale praktycznie wszystkie języki mają funkcje analizatora składni JSON. Używanie analizatora składni JSON jest znacznie wydajniejsze niż analizator składni HTML. Zajmuje mało miejsca. Nie jest tak w przypadku parsera HTML.

W PHP po prostu używasz json_encode($data)i to do klienta po drugiej stronie, aby go przeanalizować. A kiedy pobierasz dane JSON z usługi internetowej, po prostu używasz $data=json_decode($response)i możesz zdecydować, jak korzystać z danych, tak jak ze zmiennymi.

Załóżmy, że tworzysz aplikację na urządzenie mobilne, dlaczego potrzebujesz formatu HTML, gdy aplikacje mobilne rzadko używają przeglądarki internetowej do analizowania danych? Wiele aplikacji mobilnych korzysta z JSON (najpopularniejszy format) do wymiany danych.

Biorąc pod uwagę, że telefony komórkowe często korzystają z planów taryfowych, dlaczego chcesz używać HTML, który wymaga znacznie większej przepustowości niż JSON?

Po co używać HMTL, gdy HTML ma ograniczone słownictwo, a JSON może definiować dane? {"person_name":"Jeff Doe"}jest bardziej informacyjny niż dane HTML może dostarczyć na temat swoich danych, ponieważ określa tylko strukturę parserów HTML, a nie definiuje danych.

JSON nie ma nic wspólnego z HTTP. Możesz umieścić JSON w pliku. Możesz użyć go do konfiguracji. Kompozytor używa JSON. Możesz go również użyć do zapisywania prostych zmiennych w plikach.

Trudno jest sklasyfikować dobro lub zło. IMO, zadam pytania: „ czy to powinno ”, czy „czy można zrobić mniej? ”.

Każdy punkt końcowy powinien dążyć do komunikowania się przy możliwie najmniejszej zawartości. Stosunek sygnału do szumu to zwykle kody HTTP <JSON <XHTML. W większości sytuacji dobrze jest wybrać najmniej hałaśliwy protokół.

Różnię się co do obciążenia przeglądarki klienta przez @machado, ponieważ w nowoczesnych przeglądarkach nie stanowi to problemu. Większość z nich dobrze radzi sobie z kodami HTTP i odpowiedziami JSON. I chociaż nie masz obecnie testów, długoterminowe utrzymanie mniej hałaśliwego protokołu byłoby tańsze niż ten powyżej.