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

77

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?

Christopher Francisco
źródło
3
Powiązane również: stackoverflow.com/questions/1284381/… <- Bardzo dobra odpowiedź w SO.
Machado
73
Serwer używający protokołu transferu HyperText zwraca HyperText ?! Horror!
Andy
3
@Andy Szczerze mówiąc, w rzeczywistości jest to ogólny protokół przesyłania wiadomości: nic nie jest specyficzne dla przesyłania hipertekstu, w przeciwieństwie do FTP, który dużo mówi o rzeczach specyficznych dla plików i katalogów.
Joker_vD,
4
@Joker_vD Nigdy nie słyszałem o protokole o nazwie GMTP. Chociaż sytuacja ewoluowała i możesz wysyłać inne rodzaje treści przez HTTP, nie było to pierwotnym zamiarem. Chodzi mi o to, że tylko dlatego, że możesz wysyłać inne treści poza HyperText za pomocą HTTP, głupie wydaje się sugerowanie, że używanie ich do pierwotnego celu jest już nieważne.
Andy,

Odpowiedzi:

114

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?

Machado
źródło
4
Zrobiłbym krok do tyłu, zanim powiedziałbym, że to „po prostu preferencja”. Musisz podjąć kilka ważnych decyzji: czy to interfejs API, czy nie, czy mam odpowiednie biblioteki do pracy z tym jako dane JSON na kliencie, jakiego typu klienta będę obsługiwał (przeglądarki bez Javascript, dla przykład), jaki wolumen vs. czas procesora mam do dyspozycji, jaką strategię moi programiści lepiej wykorzystają itp. itd. itd.
Machado
7
„Nie trzeba interpretować kodu JS, aby tworzyć obiekty DOM - obiekty DOM już tam są, to tylko kwestia ich renderowania” - cóż, HTML już tam jest (gdy już dotrze on przez drut). Przeglądarka musi przeanalizować kod HTML i utworzyć z niego obiekty DOM.
Paul D. Waite
7
Nie ma żadnego powodu, dla którego HTML nie może działać jako interfejs API. Zero. Żaden. W rzeczywistości HAL + JSON i HAL + XML mają uderzające podobieństwo do HTML. Oto doskonała rozmowa o REST. Odpowiednia część dotycząca zwracania HTML z punktu końcowego znajduje się na końcu. youtu.be/pspy1H6A3FM Osobiście sprawiam, że wszystkie moje punkty końcowe zwracają zarówno json, jak i HTML. Jeśli piszesz wykrywalne usługi, bardzo łatwo jest je przeglądać w ... wstrzymać się ... w przeglądarce.
RubberDuck,
4
Ponieważ to kompletna dziwka, aby wyodrębnić dane, na których naprawdę zależy ci, aby spróbować ich użyć w jakikolwiek nowy sposób?
DeadMG
4
Udostępniasz HTML przez HTTP? Co to jest? Strona internetowa?
Ant P
50

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.

Robert Harvey
źródło
1
„Po pierwsze, gdy tworzysz część strony internetowej za pomocą HTML, pracujesz po stronie serwera”. Dlaczego? Nie widzę powodu, dla którego miałoby tak być. Jest to oczywiście tylko prawda w przypadku początkowego ładowania strony i prawdopodobnie nawet wtedy, ponieważ klient może wysyłać żądania danych, których potrzebuje.
DeadMG
3
@DeadMG Powinien on powiedzieć „podczas tworzenia części strony internetowej za pomocą HTML zwróconego przez serwer” (w przeciwieństwie do korzystania z JSON zwróconego przez serwer)
immibis
Rzeczywiście, ale ponieważ motywacja do tego nie ma nigdy, nie widzę sensu.
DeadMG
6
@DeadMG Mała motywacja do tego, co ma się kiedykolwiek wydarzyć? Aby serwer zwrócił HTML? Właśnie o to chodzi w tym całym pytaniu dotyczącym SE.
immibis
Pytanie dotyczy tego, czy powinieneś zwrócić HTML. Oczywiste jest, że początkową odpowiedzią musi być HTML, ale nie ma oczywistego powodu, dla którego inne interfejsy API powinny zwracać HTML.
DeadMG
22

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.

DeadMG
źródło
11
HTML może być dość ogólny. Na przykład możesz zwrócić listę wypunktowaną i umieścić ją w div, gdzie będzie ona poddana stylizacji przez dominujący CSS.
Robert Harvey
10
Nie jest to aż tak przydatne, jeśli tym razem muszę go wcisnąć. Lub renderuj w innej aplikacji, która nie jest renderowana w HTML.
DeadMG
2
Chciałbym ponownie sformułować, ponieważ zawsze będzie komponować HTML, a forma tego HTML musi zawsze być całkowicie spójna we wszystkich zastosowaniach, co nie jest bardzo pomocną gwarancją. Na przykład, w naszej aplikacji mamy list, ale w rzeczywistości nie używać uli lilecz zmienia się co każdy z nich jest div(nie pamiętam dlaczego). Byłoby to trudne, gdyby serwer zwrócił garść HTML z ulsiami lisi.
DeadMG
2
Wydaje się bezcelowe uzyskanie gwarancji w pierwszej kolejności, gdy możesz po prostu zwrócić dane i pozwolić klientowi renderować to jako HTML, jaki uzna za stosowny (jeśli w ogóle będzie to renderować)
DeadMG
1
Jedyny scenariusz, w którym widzę, w którym korzystniej byłoby zwracanie HTML, to sytuacja, w której klient nie ma wystarczających zasobów do wykonania renderowania.
DeadMG
14

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.

Victor Sand
źródło
Punkt dotyczący zmian układu brzmi bardziej jak potrzeba oddzielenia szablonów od danych bazowych, ale nie ma powodu, aby szablony te były na kliencie. Rzeczywiście istnieje wiele powodów, dla których nie ma ich na przykład, np. Nie możesz zdecydować się ukryć danych przed klientem, jeśli renderowanie odbywa się na kliencie. Częściowe strony HTML mogą być odpowiednio odświeżane, jeśli są wysyłane przez ten sam system szablonów co pełne strony HTML.
IMSoP,
6

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.

jpmc26
źródło
2
Właściwie uważam, że unikanie zduplikowanej logiki wyświetlania może być dobrym powodem do renderowania fragmentów strony HTML: jeśli renderujesz część strony na serwerze (np. Nagłówek i podstawowy układ), a następnie generujesz inne części na podstawie danych JSON na kliencie, możesz mieć dwa różne zestawy szablonów. Renderowanie części na serwerze przenosi tę logikę z powrotem do centralnej warstwy prezentacji, która może użyć tego samego szablonu do renderowania pojedynczego komponentu, tak jak gdyby statycznie składał całą stronę.
IMSoP,
1
jesteś jedyną osobą, która wspomina o telefonach komórkowych. Chcę ci za to wyrazić poparcie
Lovis,
1
@IMSoP Jeśli potrzebujesz strony dynamicznej , musisz mieć logikę front-end. Jeśli nadal renderujesz fragmenty po stronie serwera, musisz teraz upewnić się, że założenia frontonu odpowiadają warunkom wstępnym serwera konstruującego fragmenty. Nie możesz przełamać tej zależności. Synchronizowanie tej wiedzy jest trudniejsze, jeśli zostanie ona podzielona na całkowicie podzielone systemy. Jeśli renderujesz tylko w interfejsie, te założenia są scentralizowane. Myślę, że unikałbym również mieszania dynamicznego interfejsu użytkownika ze stanem początkowym w szablonie po stronie serwera; „bootstrap” do uruchomienia interfejsu jest prostszy.
jpmc26
4

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.

juhist
źródło
4

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

gnasher729
źródło
+1 Dokładnie. Pierwsze pytanie brzmi: co musisz otrzymać? Nie byłoby nic złego w zwracaniu przez punkt końcowy reklam paska bocznego jako fragmentu HTML, stopki lub podobnych elementów.
SQB,
3

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.

SouthShoreAK
źródło
5
„W nowoczesnej aplikacji kod API powinien odpowiadać za dane, a kod klienta powinien odpowiadać za prezentację”. Dlaczego tak zawsze powinno być? Zgadzam się, że jest to powszechny wzorzec i że ułatwia pewne rzeczy, ale nie widzę powodu, aby podnosić go do poziomu „powinien” ... Jest to decyzja, którą należy podjąć indywidualnie dla każdego przypadku, i z pewnością istnieją powody, dla których w niektórych sytuacjach możesz chcieć podjąć inną decyzję.
Jules
@Jules, ponieważ jeśli masz interfejs API i klienta, oboje odpowiedzialni za renderowanie stanowią naruszenie rozdzielenia obaw. (Teraz niekoniecznie masz interfejs API i klienta. Możesz mieć tylko jeden składnik i przeprowadzić całą prezentację. Ale wtedy nie masz interfejsu API)
njzk2
@ njzk2 To, że interfejs API dostarcza dane HTML, nie oznacza, że ​​je wyrenderował. Może na przykład traktować HTML jako obiekt blob i przechowywać go w bazie danych. Ponadto niektóre renderowanie może być wymagane na serwerze, a nie na kliencie (np. Zapewnienie statycznych stron dla wyszukiwarek), dlatego ponowne użycie może być postrzegane jako eliminacja duplikacji.
Jules
1
Jest również całkowicie możliwe utworzenie klienta i pary interfejsu API, w których całe renderowanie odbywa się na serwerze, a klient po prostu podłącza dostarczony kod HTML do predefiniowanych miejsc w swoim DOM. Jquery ma cały moduł dedykowany tego rodzaju klientowi, co sugeruje mi, że muszą być dość powszechne.
Jules
1
@Jules wiele rzeczy jest dość powszechnych, to nie jest powód, dla którego są one uzasadnione.
njzk2
2

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.

Joel Coehoorn
źródło
1

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.

luis.espinal
źródło
0

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.

netrox
źródło
0

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.

niebezpieczny
źródło