Odpowiedzi:
Preferuj XML zamiast JSON, jeśli jedno z poniższych jest prawdą:
Preferuj JSON zamiast XML, gdy wszystkie te kryteria są prawdziwe:
Używam JSON, chyba że muszę używać XML. Jest to prostsze do zrozumienia i (ponieważ wymaga mniejszego nakładu konfiguracji) łatwiej jest zaprogramować do czytania i pisania, jeśli biblioteki są dostępne w Twoim kontekście i są teraz dość wszechobecne.
Kiedy Amazon po raz pierwszy ujawnił swoje katalogi jako usługę internetową, zaoferował zarówno JSON, jak i XML. Około 90% implementujących wybrało JSON.
Biorąc pod uwagę twój konkretny przypadek, w którym już robisz javascript po stronie klienta, wybrałbym JSON z następujących powodów:
Ponieważ JSON jest natywny dla javascript, musiałbyś napisać mniej kodu po stronie klienta - po prostu eval()(lub jeszcze lepiej JSON.parse()) ciąg JSON i uzyskać obiekt, którego możesz użyć.
Jednocześnie ocena JSON po stronie klienta będzie wydajniejsza, a przez to szybsza.
Serializacja JSON generuje krótsze ciągi niż XML. Korzystanie z formatu JSON zmniejszy ilość danych przesyłanych w sieci i poprawi wydajność w tym zakresie.
Oto dalsze lektury: http://www.subbu.org/blog/2006/08/json-vs-xml
eval()wysyłanie JSON nie jest wielkim nie-nie?
Kilka innych rzeczy, na które natknąłem się w relm XML vs JSON:
JSON jest bardzo dobry dla
Co oznacza, że lubi tablicę lub tablicę zagnieżdżoną. Jednak w JSON brakuje obu
Jeśli więc połączysz dwie lub więcej usług JSON, mogą wystąpić potencjalne konflikty przestrzeni nazw. Biorąc to pod uwagę, JSON może być używany do około 90% tych samych rzeczy, do których XML może być używany podczas wymiany danych z mojego doświadczenia.
Zwykle JSON jest bardziej zwarty i szybszy do przeanalizowania.
Preferuj XML, jeśli:
Jeden ważny przypadek (prawie) XML: próba wykrycia, kiedy wysyłanie fragmentów HTML jest korzystniejsze niż wysyłanie surowych danych. AHAH może zdziałać cuda w prostych aplikacjach, ale często jest pomijany. Zwykle ten styl zakłada, że serwer wysyła fragmenty kodu HTML, które zostaną umieszczone na stronie internetowej bez przetwarzania.
Zwykle w przypadkach AHAH CSS jest maksymalnie wykorzystany do wizualnego masowania fragmentów kodu i implementowania prostych warunków, takich jak ukrywanie / pokazywanie odpowiednich części fragmentu przy użyciu ustawień specyficznych dla użytkownika lub aplikacji.
JSON jest łatwy i szybszy do przeanalizowania. XML jest trochę trudniejszy do przeanalizowania i wolniej jest analizować i przenosić (w większości przypadków).
Ponieważ używasz jQuery, sugeruję użycie JSON: jQuery może pobierać dane JSON i automatycznie konwertować je na obiekt Javascript. W rzeczywistości możesz przekonwertować dane JSON na obiekt JavaScript za pomocą eval . XML musiałby zostać ręcznie przez Ciebie przekrojony (nie wiem, jak to działa w Javascript, ale jest to trudne / bardziej irytujące w większości języków, z którymi korzystałem z bibliotek XML).
JSON jest zawsze preferowany ze względu na przetwarzanie, które przeglądarka klienta musi wykonać w celu przeanalizowania danych. Ponadto JSON to lekki format wymiany danych.
Parsowanie XML zawsze pochłania dużo zasobów przeglądarki i powinno się go unikać tak często, jak to możliwe, chyba że jest to wymagane.
Mam post na blogu na ten temat opisujący szczegółowo historię protokołów sieciowych (tj. SOAP, XML, JSON, REST, POX, itp.) Zawierający podsumowanie oraz niektóre zalety i wady każdego z nich: http://www.servicestack.net / mythz_blog /? p = 154
Właściwie myślę, że można wyciągnąć wiele podobieństw między XML i JSON, porównując różnice między językami dynamicznymi (JSON) i statycznymi (XML).
Zasadniczo XML jest bardziej rygorystycznym, sztywniejszym formatem serializacji, który można opcjonalnie zweryfikować za pomocą towarzyszącego schematu (którym jest XSD lub DTD). XSD są dość rozbudowane i pozwalają opisać wiele różnych typów, np. Daty, godziny, wyliczenia, typy zdefiniowane przez użytkownika, a nawet dziedziczenie typów, itp. SOAP skutecznie opiera się na zestawie funkcji XML, zapewniając ustandaryzowany sposób opisywania usług internetowych ( np. typy i operacje) poprzez WSDL. Szczegółowość i złożoność specyfikacji WSDL oznacza, że jej tworzenie może być bardziej żmudne, ale jednocześnie jest o wiele więcej dostępnych narzędzi, a większość nowoczesnych języków zapewnia zautomatyzowane narzędzia do generowania serwerów proxy klienta, które przejmują część obciążenia wyłączone podczas próby współpracy z usługami zewnętrznymi.
Nadal zalecałbym używanie XML dla twoich usług sieciowych, jeśli masz dobrze zdefiniowaną „usługę dla przedsiębiorstw”, która nie podlega częstym zmianom lub jeśli do twojej usługi sieciowej trzeba mieć dostęp w wielu różnych językach.
Mimo wszystkich zalet XML ma również wady. Opiera się na przestrzeniach nazw, aby zapewnić rozszerzalny format o określonej typie i umożliwia określenie atrybutów i elementów w tym samym dokumencie. Posiadanie różnych przestrzeni nazw w jednym dokumencie oznacza dużo czasu, gdy używasz Xml Parser do wyodrębniania danych, będziesz również musiał podać przestrzeń nazw każdego elementu, który chcesz pobrać / przejść. Ekstrapoluje również ładunek, czyniąc go bardziej szczegółowym, niż powinien. Możliwość wyświetlania atrybutów oraz elementów oznacza, że Twoje klasy nie są dobrze odwzorowane na dokument XML. Same te funkcje sprawiają, że jest on słabo dopasowany programowo do większości języków, przez co praca z nim jest bardziej żmudna i uciążliwa.
Z drugiej strony JSON jest pod wieloma względami całkowitym przeciwieństwem XML, ponieważ jest bardzo luźny i ma prostą obsługę tylko podstawowych typów: Number, Bool, string, Objects and Arrays. Wszystko inne zasadniczo musi pasować do sznurka. Nie jest to świetne, gdy próbujesz komunikować się ponad granicami języków, ponieważ będziesz musiał przestrzegać pewnych niestandardowych specyfikacji poza pasmem, jeśli chcesz obsługiwać bardziej szczegółowe typy. Z drugiej strony, jego ograniczony zestaw funkcji jest dobrze dopasowany programowo do większości języków - i jest doskonale dostosowany do JavaScript, ponieważ ciąg JSON można oszacować bezpośrednio do obiektu JavaScript.
Rozmiar i wydajność
Mam dostępne testy porównawcze bazy danych Northwind porównujące rozmiar i szybkość między implementacjami XML Microsoftu i JSON. Zasadniczo XML jest ponad 2x większy niż JSON, ale jednocześnie wygląda na to, że Microsoft włożył wiele wysiłku w optymalizację swojego XML DataContractSerializer, ponieważ jest on ponad 30% szybszy niż JSON. Wygląda na to, że musisz znaleźć kompromis między rozmiarem a wydajnością. Niezadowolony z tego faktu zdecydowałem się napisać własny, szybki JsonSerializer, który jest teraz 2,6x szybszy od XML-a MS - więc najlepsze z obu światów :).
Gdy przejdziesz przez trasę JSON, napotkasz te same problemy, z którymi borykał się XML 10 lat temu:
Mieszanie danych z dwóch różnych źródeł w jednym pakiecie JSON może powodować zderzanie się etykiet elementów. Pomieszaj list przewozowy i fakturę, a nagle adres nadawcy może oznaczać coś zupełnie innego. Dlatego XML ma przestrzenie nazw .
Konwersja między różnymi strukturami JSON wymagałaby napisania przyziemnego kodu. Bardziej deklaratywny sposób mapowania danych ułatwiłby pracę. Dlatego XML zawiera XSLT .
Opisanie struktury pakietu JSON - jego pól, typów danych itp. - jest konieczne, aby ludzie mogli podłączyć się do twoich usług. W tym celu niezbędny jest język metadanych. Dlatego XML ma schematy .
Dba o prowadzenie dwóch jednoczesnych rozmów klient-serwer. Jeśli zadasz serwerowi dwa pytania i otrzymasz jedną odpowiedź, skąd wiesz, na jakie pytanie odpowiada? Dlatego XML ma korelację WS .
Z pierwszego wiersza pod adresem http://json.org/xml.html
Extensible Markup Language (XML) to format tekstowy wywodzący się ze standardowego uogólnionego języka znaczników (SGML). W porównaniu z SGML, XML jest prosty. Dla porównania, HyperText Markup Language (HTML) jest jeszcze prostszy. Mimo to dobra książka o HTML ma grubość cala. Dzieje się tak, ponieważ formatowanie i strukturyzacja dokumentów to skomplikowana sprawa. . . .
Oczywiście JSON jest szybszy, ale jest jeszcze wyraźniejszy, że jest trudny do odczytania. Użyj JSON dla szybkości, użyj XML, jeśli będzie interakcja międzyludzka i możesz poświęcić szybkość.
Używam JSON do wszelkiego rodzaju konfiguracji, wymiany danych lub przesyłania wiadomości. Używam XML tylko wtedy, gdy muszę z innych powodów lub semantycznie oznaczyć dane podobne do dokumentów.
Zarówno XML, jak i JSON są obsługiwane przez firmę Microsoft. Literały XML były nową fajną funkcją w VB 9. W nadchodzącej wersji ASP.NET 4.0 JSON jest koniecznością, aby wykorzystać moc szablonów po stronie klienta.
Z pytania, które zadałeś, wydaje się, że JSON może być wyborem dla Ciebie, ponieważ jest łatwy do przetworzenia po stronie klienta z lub bez jQuery.
Korzystanie z formatu JSON
Korzystanie z XML
Znalazłem ten artykuł na cyfrowym bazarze naprawdę interesujący.
Poniżej zacytowano niektóre fragmenty artykułu.
O plusach JSON:
Jeśli wszystko, co chcesz przekazać, to wartości atomowe lub listy lub skróty wartości atomowych, JSON ma wiele zalet XML: jest łatwy do użytku w Internecie, obsługuje szeroką gamę aplikacji, łatwo jest pisać programy do przetwarzania JSON, ma kilka opcjonalnych funkcji, jest czytelny dla człowieka i dość przejrzysty, jego projekt jest formalny i zwięzły, dokumenty JSON są łatwe do utworzenia i wykorzystuje Unicode. ...
O profesjonalistach XML:
XML niezwykle dobrze radzi sobie z pełnym bogactwem nieustrukturyzowanych danych. W ogóle nie martwię się o przyszłość XML, nawet jeśli jego śmierć jest radośnie obchodzona przez kadrę projektantów internetowych API.
I nie mogę się powstrzymać i nie mogę się powstrzymać i nie mogę się powstrzymać i nie mogę się oprzeć w moim biurku. Z niecierpliwością czekam na to, co zrobią ludzie z JSON, gdy zostaną poproszeni o opracowanie bogatszych interfejsów API. Kiedy chcą wymienić dane o słabszej strukturze, czy wrzucą je do formatu JSON? Od czasu do czasu widzę wzmianki o języku schematu dla JSON. Czy pojawią się inne języki? ...
Szybkie zasady:
Wyjaśnienie:
Jedyną rolą JSON jest serializacja danych obiektowych przy użyciu typów danych wspólnych dla większości języków programowania: list , skrótów i skalarów , iw tym celu naprawdę nie można tego przebić ani ulepszyć. W związku z tym „JSON nie ma numeru wersji [as] nie przewiduje się żadnych zmian gramatyki JSON”. - Douglas Crockford (Nie można tego pobić jako znaku, że doskonale wykonujesz swoją pracę)
XML był kiedyś sprzedawany jako format wymiany danych, ale rozważ dwa najczęstsze przypadki użycia: asynchroniczna komunikacja klient-serwer (AJAX) - JSON prawie całkowicie zastąpił XML (X powinien naprawdę być J) oraz usługi sieciowe : JSON sprawił, że XML stał się zbędną alternatywą.
Inną rzeczą, do której XML był szeroko używany, były pliki danych do zapisu / odczytu (?) Dla programów, ale tutaj również masz bardziej zwięzły, bardziej przyjazny programom, bardziej przyjazny dla człowieka format w YAML, nadzbiór JSON.
Tak więc pod względem reprezentacji danych JSON przewyższa XML na całej planszy. Co w takim razie zostało dla XML? Reprezentacja dokumentów o mieszanej treści, do czego była przeznaczona .
Większość nowszych technologii internetowych działa przy użyciu formatu JSON, więc zdecydowanie jest to dobry powód do korzystania z formatu JSON. Ogromną zaletą jest to, że w XML można przedstawić na wiele różnych sposobów te same informacje, co w JSON jest prostsze.
Również JSON IMHO jest znacznie bardziej przejrzysty niż XML, co daje mi wyraźną przewagę. A jeśli pracujesz z .NET, Json.NET jest wyraźnym zwycięzcą, jeśli chodzi o pomoc w pracy z JSON.