API Formats: Why JSON won over XML
ฝัง
- เผยแพร่เมื่อ 9 มิ.ย. 2024
- Why did JSON replace XML as the preferred representation format for APIs? There are many reasons one can speculate about, and there probably is no way to isolate one single reason, or to even find the main reason.
But it is possible to have opinions about this, and in this video I explain one of the factors that in my experience contributed greatly to JSON being preferred over XML. Other factors of course played a role as well, such as XML's verbosity and the rather complex ecosystem of related specifications.
But one main factor was that XML at its heart is a document format. It is great for representing documents, and it can represent data, but that's not its strong suit. Being a document-focused format, it represents everything as trees, which then have to be traversed in order to process information from those documents. That results in extra work and a cognitive dissonance between the data that is being represented in APIs (in XML's document-centric format) and the way how most applications internally represent data (oftentimes in structured object models).
JSON came along and changed that by simply reusing the object model of an existing language (JavaScript, as JSON simply stands for JavaScript Object Notation). That was a much better fit for most APIs (which often are using structured data and not documents) and developers (who often work in languages that have object models close to JSON). This meant no more parsing and traversing of XML trees, instead the JSON objects could be relatively directly mapped into native data structures.
You're more than welcome to disagree (please comment if you do!), and this is of course an opinionated and slightly exaggerated view. But it is one of the factors that are often overlooked, so giving it a bit more visibility seemed appropriate.
![[Full Episode] MasterChef Junior Thailand มาสเตอร์เชฟ จูเนียร์ ประเทศไทย Season 3 Episode 2](http://i.ytimg.com/vi/YpQnHoQvZt4/mqdefault.jpg)
I cannot overstate how much I appreciate a video on the WHY of computer programming formats and concepts and not just another generic HOW video.
Thanks for this video. I’m currently working on a project that needs some data, basically lists of protocols for radiation therapy plans. I wanted to avoid adding a database initially, so I created the protocols in a plain text document using xml. But over the last week I’ve been thinking json would probably have been better. Your video pushed my 100% there. Will be converting xml to json. May even bite the bullet and create the database.
While there are XML databases they are not super popular. So if your structured data should be available in a database to store and query at scale, choosing JSON probably is a better idea.
This is where all technical discussions should begin, the “Why?”.
What problem compelled the choices or the reality we live in…I don’t understand why in the modern world we care so little about the “Why?”. I believe it is why we end up feeling trapped learning and using the wrong tools, the problem the tools were built to solve has long been solved and now we have new problems but the tool we are using became dogma.
I couldn't agree more!
I always wondered why some formats were used when others were, in my opinion, so much better - like certainly they had reasons, but how am I to see the value of a format if i dont know those reasons?
How am I to even actually know what is good? Or to learn to develop new good stuff?
That is also probably why there is so much reinventing the wheel going on - people just forget about stuff because those inbetween didnt see reasons to keep them.
I like the way you structured the content in the video. Simple and interesting!
Thanks a lot, @Roger!
Really appreciate the history of the 2 formats. Great content. Thank you
Great video and to the point! When I started using XML for "real world" data back in the 1990s I really found my self in a straight jacket. A "huge" problem was double hiearchies, which often occurs in the real world and seldom in documents. Then it occured to me that XML was really the same data model as the IBM IMS from the mid 1960s. In my early dbms design and development I used the Codasyl network model which included that a node could be part of two different hiearchies, i.e. had a parent and a step-parent,direct link from grandchild to grandparent and so on. So I though of XML as pre Codasyl (Network model), i.e. modeling pre 1970s. When JSON came about it was also a flash back, since it in a way like re-inventing th Relational Datamodel (Codd 1974). And I finally could use objects, lists and arrays like in a relational DBMS and with less "rules"
Sounds like the lesson we all learn sooner or later. Hard problems in communications or semantics never get magically removed by specific technologies. All those can do is to give us a hopefully better starting point to manage them.
Great explanation! Thanks!
Great video, thank you for your time
Nice video. Thanks for posting
Graet explaination
thanks ❤
Because they took the JavaScript engine from the browser and put it on the server. It's a natural choice for communicating between a client and API that are both written in JavaScript.
Thanks.?.very easy to understand.
For sure DOM hurt XML, and for sure JSON is a better fit when the programmer is in total control of the format. It's not 100% true that we didn't think about such infrastructure use cases when developing XML, but you're right that documents were primary.
thanks for the comment, liam. i am sure you remember that i always was a big fan of XML, and i still am. but here it's all about the famous maslow quote, and XML turned out not to be such a great hammer for most API nails.
What I dislike about both of them is that both are in effect trees. I want the power of a graph.
Then you should check out RDF. You'll love it!
Seems to me a huge weakness of XML is that you need a schema to parse the basics like: is this node an array? Is this value a string, bool or number?
In JSON at least you know that much.
It's true that XML doesn't have the kind of "data-oriented" typing that JSON has (even though it's extremely minimal in JSON). But that's because XML wasn't intended to be a data format. There's a minimal type model for attributes, but that again never was intended for data typing.
@@ErikWilde True. I guess that's why it lost as a data format. Intended for something else than how most web apps use data. (as you did mention in the video 👍)
Why is Antonio Banderas giving a lecture on JSON 😳
Great post ! I completely agree and buy your hypothesis. There is one thong though that doesn't fit and this is that most Document oriented databases (like MongoDB or CouchDB) use JSOn and not XML to store structured documents. Could it be that these engines are used within JabaScript code ?
To be honest, i don't consider MongoDB or CouchDB to be document databases. They are NoSQL for sure, but if you're serious about structured documents, it's unlikely that you would choose JSON as your foundation. It seems that the term "document database" has a rather fuzzy meaning nowadays, and mostly refers to the fact that you can store "entire objects/documents" (as opposed to SQL and its fine-grained row structure). In my mind, when people talk about "document databases", it rarely is specifically about storing actual documents (in the sense of semi-structured and mixed content).
What about complex json structures? Are you not thinking of mini api's versus bigger api's? The complexity is moving away/out of the one data structure but reappearing in the orchestration of the many api's... no?
there is complexity (the "natural complexity" of a domain) and complication (the "artificial complexity" added by picking a particular solution/technology. you cannot make complexity go away, but i think that the "XML complication" is something that most developers saw being removed for them in JSON-based approaches.
many other things play into this. for example the emergence of GraphQL, which moved complexity from multiple API interactions to a more manageable complexity in a single API with a schema and query language. shifting complexity around always is very much a design exercise.
but XML (for most applications and users) simply was a complication: the trees, the element/attribute duality, namespaces, data binding and serialization: none of that came from the domain, it was just XML complication.
@@ErikWilde lets put in simple words : How we will represent the JSON for the structure that you have shown in you video where we have paragraph with some embedded text, anchors, references etc. kind of mixed data model to use conveniently with other object?
@@vishnusingh2245 to be honest, i don't think that there's a reasonable way to represent that example in JSON. that's where XML is more flexible with allowing mixed content (characters mixed with elements) and much more variety in its structures. i am sure you can come up with *some* JSON representing the XML document snippet, but using it would be almost certainly excruciatingly painful to use for anything.
@@vishnusingh2245 what a stupid question!!!
@@aledesc I don't think asking questions is a stupid thing in TechWorld. We just need to learn and explore!
I too catched up with XML, SOAP is still a thing, what most disliked that XSD /XSLT, Xpath , it just to verbose. In SOAP you need to maintain the WSDL on client and server side, and of course it did many times wrong.
API for whom? For many backend developers we live by XML and it's technologies. It's other things for frontend developers
02:30 1998
Content is great...audio sucks
Before XML you had standards like the horrible EDIFACT for machine to machine communications, compared to them XML is a bless and JSON is even better.
en.wikipedia.org/wiki/EDIFACT