Comment by mikepurvis
20 hours ago
HTML was conceived as a language for marking up a document that was primarily text; XML took the tags and attributes from that and tried to turn it into a data serialization and exchange format. But it was never really well suited to that, and it's obvious from looking XML-RPC or SOAP payloads that there were fundamental gaps in the ability of XML to encode type and structure information inline:
<?xml version="1.0"?>
<methodCall>
<methodName>math.add</methodName>
<params>
<param>
<value><int>5</int></value>
</param>
<param>
<value><int>7</int></value>
</param>
</params>
</methodCall>
Compared to this, JSON had string and number types built in:
{
"jsonrpc": "2.0",
"method": "math.add",
"params": [5, 7],
"id": 1
}
I don't think this is the only factor, but I think XML had a lot of this kind of cognitive overhead built in, and that gave it a lot of friction when stacked up against JSON and later yaml... and when it came to communicating with a SPA, it was hard to compete with JS being able to natively eval the payload responses.
To be fair I cannot trust your shape in your jsonrpc, I am not sure if id is truly an integer or if you sent me an integer by mistake, same as params or even the payload of the params' param, this is why we ended adopting openapi for describing http interactions and iirc jsonrpc specifically can also be described with it. At least in the schema part no one would say it is ambiguous, also one does not need do heavier parses, the obj is a tree, no more checking on scaping strings, no more issues with handcoded multiline strings, it is dropped the need to separate attributes with commas as we know the end tag delimits a space and so on.
> To be fair I cannot trust your shape in your jsonrpc, I am not sure if id is truly an integer or if you sent me an integer by mistake, same as params or even the payload of the params' param
In practice, it doesn't matter.
If the JSON payload is in the wrong format the server rejects it with an error.
If the server sends an integer "by mistake" then the purists would argue that the client should come to a halt and throw up an error to the user. Meanwhile the JSON users would see an integer coming back for the id field and use it, delivering something that works with the server as it exists today. Like it or not, this is why JSON wins.
Schema defined protocols are very useful in some circumstances, but in my experience the added overhead of keeping them in sync everywhere and across developers is a lot of overhead for most simple tasks.
Putting the data into a simple JSON payload and sending it off gets the job done in most cases.
Yeah this is the issue. I spent tons of time writing code that would consume xml and turn it into something useful.
It’s a mediocre data storage language.