101–110 of 188 posts
Why does some people want to over-engineer it?
> { "$id": "http://xn--rvg" }
Oh no. Please don’t do that.
Earlier quoted context omitted.
Strongly agree - I've worked with ONC RPC, CORBA, SOAP, XML & XSD, XSLT etc. and I much prefer the relatively straightforward nature of JSON and JSON Schema. Yes it's not perfect - but for me it is more than good enough. Edit: Of course, there is no direct equivalent of XSLT in the JSON world - which pretty much counts as a feature to me.
Nor XPath.
Earlier quoted context omitted.
XSD is not as bad as everyone claims. JSON Schema vs. XSD complexity is IMHO pretty much the same. Working with both over years. DTD however, let us not talk about that. Let us just forget it. I think the drama in XML usage was basically that a simple RPC (or resource query) had at least a dozen namespaces, standards and very long element names. But that is not the fault of XML but of SOAP/WS-*. XML itself can be ver…
Maybe someone can chime in but parsing XML seems very much more difficult than parsing JSON.
As a consequence, JSON in JavaScript is super easy. Using XML is medium-hard.
In .NET using XML or JSON is easy (not super easy).
In C++ using XML or JSON is medium-hard.
Do not know the state of the art for Go, Rust, Java, ...
As a consequence, JSON is - from a JavaScript developer perspective - the holy grail. From a .NET/Java/C++ developer perspective it is just another format.
Earlier quoted context omitted.
Do you mean XSD? XSD = JSONSchema WSDL = OpenAPI SOAP = there really isn't a direct analog maybe ""REST"" --- In any case, try creating a SOAP service and WSDL. It's literally so complex that most tutorials have to rely on an IDE to do it. Humans are simply not equal to the task. Yes, the purpose is similar, but only those who have never used them would think they're the same.
Well let's turn the statement around then: can you create a OpenAPI YAML by hand then? At least with XML and XSD you have proper auto complete. I really no need see the need to use a schema for JSON. The only thing it has going for it compared to SOAP/XML is the fact the it faster parsing and that it has no schema.
Of course.
> At least with XML and XSD you have proper auto complete.
Tooling for OpenAPI exist. In VS Code for example.
> I really no need see the need to use a schema for JSON
Don't you see the need for precise machine readable description of JSON input and output for a REST API for validation? This is OpenAPI..
Earlier quoted context omitted.
I had to use SOAP once... for one API endpoint. I'd say it was the worst dev experience of my whole career, and I fought with objective-c and app stores.
Using SOAP APIs daily since over 15 years with .NET Framework development. Simple and easy to write and then easy to consume through Visual Studio generated code. Tried some ObjC development early on the iPhone. Gave up quickly. I agree that SOAP looks like a mess. But given the right tools, it honestly just works. Never had a single issue with these APIs apart being stuck in .NET Framework land.
Which I would agree is most of the time - but then it doesn't and you have to try and work out what is going wrong from reams of impenetrable generated WSDL. Which is fun.
Earlier quoted context omitted.
> Developers don't like complexity. Judging by the code that is in front of me right now, I'm pretty sure they really do like it... or at least make lots of it.
They like to produce complexity, else they get bored while writing the code. But they don't like OTHER developer's complexity.
I'd like to offer a contrasting opinion to all of the other currently negative comments: I've used JSON schema in the past to validate outside input and it was a pleasant and straightforward experience. There are unfortunately no standard type declarations that I'm aware of, which is a pain, but tools exist to translate schema.org schemas[1] (I have not used this myself). [1]: https://github.com/charlestati/schema-or…
When I used JSON schema last time a few years ago the different implementations of it in PHP and nodejs where either incorrect of feature incomplete. Seems like it is hard to get right.
Earlier quoted context omitted.
XSD is not as bad as everyone claims. JSON Schema vs. XSD complexity is IMHO pretty much the same. Working with both over years. DTD however, let us not talk about that. Let us just forget it. I think the drama in XML usage was basically that a simple RPC (or resource query) had at least a dozen namespaces, standards and very long element names. But that is not the fault of XML but of SOAP/WS-*. XML itself can be ver…
> I think the drama in XML usage ... What about: - verbosity - complexity of writing a parser - complexity of dumping data - DTDs - data model which doesn't map directly to a scalar/array/associative array ... and so many other XML features that are either useless or painful just for RPC.
Parser writing and dumping of data is equally complex for both JSON and XML. The only difference is that in JavaScript JSON is so much simpler due to the dynamic nature of the language and the core library. Out-of-the-box XML parsing in JS is just stone-age. Compare that to .NET System.Xml.XDocument and Newtonsoft.Json, then you can see the simplicity how an API could look (in a static type system ;))
No one needs DTDs. No modern contract is every spec'ed in DTDs. XSDSchema has superseeded that 20 years ago. The only issue with it, is that some entry level tutorials are still mentioning it.
The data model mapping depends a lot on the target language. In JavaScript XML is not a match but JSON is. Working with JSON in C++ is equally stupid as working with XML is.
The only stupid feature in XML is namespaces. Without that, it is simple.
We've come full circle back to XML SOAP. We should consider restricting the registration of .org domains to actual non-profit organizations, and restricting the use of words like "schema" and "standard" to things that have been fully certified as such by internationally accredited engineering bodies. This doesn't add anything on-top of the tools we've had 40 years ago. We're stuck with this everywhere now, all thanks…
JSON syntax is more familiar for people who have not been exposed to XML for long. Parsing and walking a JSON structure is much easier and less ambiguous. It's often very clear how to represent/deserialize/serialize JSON (as-is). The benefits of using schema are clear, you can add validation and semantics to parse (JSON) into a richer and more consistent data structure. JSON-schema is in large parts a well designed a…
Attributes are absolutely one of the reasons for XML's failure. They seem so innocuous, until you encounter a schema where the developer created:
Nevermind if you've ever encountered XML with mixed namespaces. Then again, reading the article the bit at the end is exactly the same sort of nastiness.
Earlier quoted context omitted.
> Developers don't like complexity. Judging by the code that is in front of me right now, I'm pretty sure they really do like it... or at least make lots of it.
They like to produce complexity, else they get bored while writing the code. But they don't like OTHER developer's complexity.
But it’s complex and difficult to grasp, so it’s not fun when you have to get into someone else’s mind, or even to get back into your own thinking after period of a sense of that project/architecture