Dlaczego wszyscy wybierają JSON zamiast XML dla jQuery? [Zamknięte]

Pomyślałem, że XML jest bardzo przenośny i może być używany jako mini baza danych. Wszędzie widziałem XML używany. Widzę nawet, jak duże firmy przechodzą na JSON . Nawet Microsoft ma zintegrowaną obsługę JSON. O co tyle szumu wokół JSON?

Zasadniczo, ponieważ JSON jest natywnie rozpoznawany przez JavaScript, jest naprawdę lekki, minimalistyczny i wysoce przenośny, ponieważ opiera się tylko na dwóch podstawowych strukturach:

• Zbiór par nazwa / wartość. W różnych językach jest to realizowane jako obiekt, rekord, struktura, słownik, tabela skrótów, lista z kluczami lub tablica asocjacyjna.
• Uporządkowana lista wartości. W większości języków jest to realizowane jako tablica, wektor, lista lub sekwencja.

XML nie zaczyna świecić, dopóki nie zaczniesz mieszać różnych schematów z przestrzeniami nazw. Następnie widzisz, że JSON zaczyna spadać, ale jeśli potrzebujesz tylko formatu serializacji danych, JSON jest mniejszy, lżejszy, bardziej czytelny dla człowieka i ogólnie szybszy niż XML.

Uważam, że dużą zaletą JSON w porównaniu z XML jest to, że nie muszę decydować, jak sformatować dane. Jak niektórzy pokazali, istnieje wiele sposobów na zrobienie nawet prostych struktur danych w XML-u - jako elementy, jako wartości atrybutów, itp. Następnie musisz to udokumentować, napisać schemat XML lub Relax NG lub inne bzdury ... bałagan.

XML może mieć swoje zalety, ale w przypadku podstawowej wymiany danych JSON jest znacznie bardziej zwarty i bezpośredni. Jako programista Pythona nie ma niezgodności impedancji między prostymi typami danych w formacie JSON i Python. Więc gdybym pisał moduł obsługi po stronie serwera dla zapytania AJAX, który pytał o warunki śniegowe w konkretnym ośrodku narciarskim, utworzyłbym następujący słownik:

conditions = {
    'new_snow_24': 5.0,
    'new_snow_48': 8.5,
    'base_depth': 88.0,
    'comments': 'Deep and steep!',
    'chains_required': True,
}
return simplejson.dumps(conditions)   # Encode and dump `conditions` as a JSON string

Po przetłumaczeniu przez JSON (przy użyciu biblioteki takiej jak „simplejson” dla Pythona), wynikowa struktura JSON wygląda prawie identycznie (z wyjątkiem JSON, wartości logiczne są pisane małymi literami).

Dekodowanie tej struktury wymaga tylko parsera JSON, niezależnie od tego, czy jest to JavaScript, czy Objective-C dla natywnej aplikacji na iPhone'a, C # lub klienta Pythona. Pływaki byłyby interpretowane jako zmiennoprzecinkowe, ciągi znaków jako łańcuchy, a wartości logiczne jako wartości logiczne. Używając biblioteki „simplejson” w Pythonie, simplejson.loads(some_json_string)instrukcja zwróciłaby mi pełną strukturę danych, taką jak właśnie utworzyłem w powyższym przykładzie.

Gdybym napisał XML, musiałbym zdecydować, czy robić elementy, czy atrybuty. Oba są ważne:

<conditions>
    <new-snow-24>5</new-snow-24>
    <new-snow-48>8.5</new-snow-48>
    <chains-required>yes</chains-required>
    <comments>deep and steep!</comments>
</conditions>

<conditions newSnow24="5" newSnow48="8.5" chainsRequired="yes">
   <comments>deep and steep!</comments>
</conditions>

Muszę więc nie tylko myśleć o danych, które chcę wysłać do klienta, ale także o tym, jak je sformatować. XML, chociaż jest prostszy niż zwykły SGML, ponieważ jest bardziej rygorystyczny ze swoimi regułami, nadal zapewnia zbyt wiele sposobów myślenia o tych danych. Wtedy musiałbym go wygenerować. Nie mogłem po prostu wziąć słownika Pythona (lub innej prostej struktury danych) i powiedzieć „zrób sobie sam XML”. Nie mogłem otrzymać dokumentu XML i od razu powiedzieć „idź zrób z siebie obiekty i struktury danych” bez pisania niestandardowego parsera lub bez konieczności dodatkowego narzutu XML Schema / Relax NG i innych podobnych problemów.

Krótko mówiąc, kodowanie i dekodowanie danych do formatu JSON jest znacznie łatwiejsze i znacznie bardziej bezpośrednie, szczególnie w przypadku szybkich wymian. Może to dotyczyć osób pochodzących z dynamicznego tła językowego, ponieważ podstawowe typy danych (listy, słowniki itp.) Wbudowane w JavaScript / JSON bezpośrednio odwzorowują te same lub podobne typy danych w Pythonie, Perlu, Ruby itp.

Wydajność JSON nie różni się zbytnio od XML w większości przypadków użycia, JSON nie jest dobrze dopasowany i czytelny dla struktur głęboko zagnieżdżonych ... napotkasz]]]}], co utrudnia debugowanie

Jest lekki w porównaniu z XML. Jeśli potrzebujesz skalować, zmniejsz wymagania dotyczące przepustowości!

Porównaj JSON

 [
      {
           color: "red",
           value: "#f00"
      },
      {
           color: "green",
           value: "#0f0"
      },
      {
           color: "blue",
           value: "#00f"
      },
      {
           color: "cyan",
           value: "#0ff"
      },
      {
           color: "magenta",
           value: "#f0f"
      },
      {
           color: "yellow",
           value: "#ff0"
      },
      {
           color: "black",
           value: "#000"
      }
 ]

do XML:

 <colors>
      <color >
           <name>red</name>
           <value>#f00</value>
      </color>
      <color >
           <name>green</name>
           <value>#0f0</value>
      </color>
      <color >
           <name>blue</name>
           <value>#00f</value>
      </color>
      <color >
           <name>cyan</name>
           <value>#0ff</value>
      </color>
      <color >
           <name>magenta</name>
           <value>#f0f</value>
      </color>
      <color >
           <name>yellow</name>
           <value>#ff0</value>
      </color>
      <color >
           <name>black</name>
           <value>#000</value>
      </color>
 </colors>

Tylko anegdota z własnego doświadczenia:

Napisałem mały katalog Javascript, najpierw z danymi w XML, a następnie dostosowałem go do korzystania z JSON, aby móc je uruchamiać obok siebie i porównywać prędkości z Firebug. JSON okazał się być około 3 razy szybszy (350-400 ms w porównaniu z 1200-1300 ms do wyświetlenia wszystkich danych). Ponadto, jak zauważyli inni, JSON jest znacznie łatwiejszy dla oczu, a rozmiar pliku był o dobre 25% mniejszy ze względu na mniejszą liczbę znaczników.

 <colors>
      <color name='red'     value='#f00'/>
      <color name='green'   value='#0f0'/>
      <color name='blue'    value='#00f'/>
      <color name='cyan'    value='#0ff'/>
      <color name='magenta' value='#f0f'/>
      <color name='yellow'  value='#ff0'/>
      <color name='black'   value='#000'/>
 </colors>

Z atrybutami XML jest fajny. Ale z jakiegoś powodu domowy XML jest generalnie w 100% złożony z elementów i brzydki.

Łatwe korzystanie z JavaScript może być jednym z powodów ..

JSON jest najlepszy do wykorzystania danych w aplikacjach internetowych z usług sieciowych ze względu na jego rozmiar i łatwość użycia, szczególnie ze względu na wbudowaną obsługę JavaScript . Wyobraź sobie obciążenie obliczeniowe związane z analizowaniem fragmentu XML w porównaniu z natychmiastowym wyszukiwaniem w formacie JSON.

Bardzo dobrym przykładem jest JSON-P. Możesz odzyskać dane z usługi sieciowej opakowane w wywołanie funkcji zwrotnej, na przykład my_callback({"color": "blue", "shape":"square"});wewnątrz dynamicznie generowanego <script>tagu, dzięki czemu dane mogą być bezpośrednio wykorzystane w funkcji my_callback(). Nie ma sposobu, aby zbliżyć się do tej wygody za pomocą XML.

XML byłby formatem wybieranym dla dużych dokumentów, w których istnieje struktura renderowania stron danych w wielu formatach przy użyciu XSLT. XML może być również używany z plikami konfiguracyjnymi aplikacji ze względu na czytelność wśród wielu innych zastosowań.

Nikt tutaj nie wspomniał o głównych zaletach XML-ów: regułach walidacji (DTD, XSD). Moje wnioski, korzystając z obu:

• JSON jest idealny dla Ajax, szczególnie jeśli sam tworzysz zarówno po stronie serwera, jak i klienta. Zasadniczo tworzysz obiekty js bezpośrednio w skrypcie serwera!
• XML błyszczy w środowiskach korporacyjnych, kiedy trzeba ustalić standardy wymiany danych między dużymi biurokratycznymi organizacjami. Często jedna ze stron opracowuje swoją część kilka miesięcy przed drugą, więc naprawdę zyskuje na walidacji swoich wniosków pod kątem uzgodnionego XSD. Ponadto w dużych korporacjach transfer danych jest często tłumaczony między różnymi systemami. To także siła XML, myślę XSLT. Przykład: konwersja bezkodowa do JSON: s

Oczywiście opracowywany jest schemat json, ale nigdzie nie znajdziesz do niego wbudowanej obsługi.

Jestem fanboyem obu, mają po prostu różne mocne strony.

Teraz, gdy istnieją kodery i dekodery JSON dla większości języków, nie ma powodu, aby NIE używać JSON do zastosowań, w których ma to sens (i to prawdopodobnie 90% przypadków użycia XML).

Słyszałem nawet o ciągach JSON używanych w dużych bazach danych SQL w celu ułatwienia zmiany schematu.

Szczerze mówiąc, JSON i XML nie różnią się tak bardzo tym, że mogą reprezentować wszystkie typy danych. Jednak XML jest składniowo większy niż JSON, co sprawia, że ​​jest cięższy niż JSON.

JSON nie ma niezgodności impedancji z programowaniem JavaScript. JSON może zawierać liczby całkowite, ciągi znaków, listy, tablice. XML to tylko elementy i węzły, które muszą zostać przeanalizowane na liczby całkowite i tak dalej, zanim będzie można je wykorzystać.

Oba są świetne i bardzo przenośne. Jednak JSON zyskuje na popularności, ponieważ w większości przypadków serializuje się na mniej znaków (co przekłada się na szybszy czas dostawy), a ponieważ pasuje do składni obiektu JavaScript, można go bezpośrednio przetłumaczyć na obiekt w pamięci, co znacznie ułatwia Ajax wprowadzić w życie.

XML jest nadal świetny. JSON to po prostu „najnowsze i najlepsze” w porównaniu do XML.

Łatwo analizowany przez JavaScript i lekki (dokument w formacie JSON jest mniejszy niż dokument XML zawierający te same dane).

JSON jest efektywnie zserializowanym JavaScriptem, ponieważ można ewaluować (aJsonString) bezpośrednio do obiektu JavaScript. W przeglądarce jest oczywiste, że JSON doskonale nadaje się do obsługi JavaScript. W tym samym czasie JavaScript jest językiem dynamicznym o bardzo luźnym typie i nie może natywnie korzystać ze wszystkich dostępnych informacji o typie, zawartych w dokumencie Xml / Xsd. Te dodatkowe metadane (które świetnie nadają się do współdziałania) utrudniają JavaScript, czyniąc go bardziej żmudnym i obszerniejszym w użyciu.

Rozmiar a wydajność

Jeśli jesteś w przeglądarce, JSON jest szybszy do serializacji / deserializacji, ponieważ jest prostszy, bardziej kompaktowy i, co ważniejsze, obsługiwany natywnie. Mam dostępne testy porównawcze bazy danych Northwind, porównujące rozmiar i prędkość między różnymi dostępnymi serializatorami. W bibliotece klas bazowych serializator XML DataContract firmy Microsoft jest ponad 30% szybszy niż ich JSON. Chociaż ma to więcej wspólnego z wysiłkiem, jaki Microsoft włożył w ich serializator XML, ponieważ udało mi się opracować JsonSerializer, który jest ponad 2,6x szybszy niż ich XML. Jeśli chodzi o ładunki oparte na testach porównawczych, wygląda na to, że XML jest z grubsza większy niż 2xrozmiar JSON. Może to jednak szybko ulec zniszczeniu, jeśli ładunek XML używa wielu różnych przestrzeni nazw w tym samym dokumencie.

XML jest w większości sytuacji rozdętym olejem węża. JSON daje większość korzyści bez wzdęć.

Jedna główna zaleta, inna niż te wymienione tutaj. W przypadku tych samych danych istnieje wiele sposobów na przedstawienie ich jako pliku XML, ale tylko jeden sposób w przypadku formatu JSON eliminuje niejednoznaczność :)

Nie jestem żadnym ekspertem, ale z różnych firm, dla których pracowałem, zazwyczaj używamy XML w środowiskach małych danych lub wartości konfiguracyjnych (web.config jest świetnym przykładem).

Jeśli masz duże ilości danych, zazwyczaj będziesz chciał raportować te dane. A XML nie jest doskonałym źródłem raportów. W ogólnym rozrachunku wydaje się, że transakcje w bazie danych są łatwiejsze do raportowania / wyszukiwania niż XML.

Czy to ma sens? Jak powiedziałem powyżej, nie jestem ekspertem, ale z mojego doświadczenia wynika, że ​​tak jest. Uważam również, że zintegrowana obsługa JSON firmy Microsoft ze względu na falę deweloperów przechodzących do działań po stronie klienta lub skryptów w celu ulepszenia wizualizacji interfejsu użytkownika ( Ajax ), a Microsoft Ajax nie był używany tak często, jak inne biblioteki, takie jak jQuery i MooTools ( Yahoo's YUI jest również w tej mieszance) ze względu na ich piękną integrację obiektów możliwych do serializacji przy użyciu JSON.

Piszę kod teraz implementując serializator JSON w moim kodzie VB. To ZNACZNIE zbyt proste iz punktu widzenia aktualizacji / modyfikacji, nie możesz tego pokonać. Myślę, że to sposób Microsoftu na uzależnienie nas od VS. Niedawno przekonwertowałem aplikację korporacyjną na używającą Ajax (przez jQuery) i używającą formatu JSON. Zajęło to około 2 tygodni. Właściwie dziękuję Microsoftowi za integrację, ponieważ bez niego musiałbym napisać sporo dodatkowego kodu.