Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JSON Schema bundling formalised

json-schema.org

Post reply on HN
Print view View original

81–90 of 188 posts

Re: JSON Schema bundling formalised

#81

Post by k__ »

m_st wrote: post #66
k__ wrote: post #58

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.

Yes, I had to use it in a Node.js project.

Would imagine, with the right tooling and TypeScript it wouldn't have been that bad.

Re: JSON Schema bundling formalised

#82

Post by lwn »

jacobmischka wrote: post #18

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…

I'm using json schema all the time. The big step forwards for me is I can validate data everywhere down the application pipeline, no matter the programming language, using a single document (single source of truth), and it's human readable.

Re: JSON Schema bundling formalised

#83

Post by easrng »

oaiey wrote: post #77
dgb23 wrote: post #68

Earlier quoted context omitted.

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…

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…

It's easy in JS too, just use a DOMParser

Re: JSON Schema bundling formalised

#84

Post by meltedcapacitor »

oaiey wrote: post #77
dgb23 wrote: post #68

Earlier quoted context omitted.

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…

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…

Namespaces killed xml. Such a bad design. It may have worked out better with every schema required to explicitly flatten in whatever they need from sub-grammars.

I see this json schema thing also seems to use long intricate URLs that you can only copy-paste to identify things... at least in this day and age if one does ID with unwieldy blobs, it'd be good to at least use some hash to get the benefits of content addressing.

Re: JSON Schema bundling formalised

#85

Post by IggleSniggle »

ivolimmen wrote: post #70
paulddraper wrote: post #54

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.

You can get proper autocomplete out of OpenAPI, powered by typescript.

Re: JSON Schema bundling formalised

#86

Post by indymike »

atombender wrote: post #69

I'll be one of the few positive voices here, I guess. JSON Schema is pretty good. It's a relatively simple, extensible, pragmatic specification that supports validating the kinds of data that JSON can express. XML was killed by complexity, same as lots of technologies that preceded it, such as CORBA and SOAP. Developers don't like complexity. W3C tried to build an enormously complicated ecosystem of tools on top of X…

> 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.

Re: JSON Schema bundling formalised

#87

Post by akie »

vbezhenar wrote: post #48
akie wrote: post #3

I might be exceptionally dense, but it's hard for me to see practical applications for something like this. In the end, if you implement this in your application, you will have a mechanism to say "this input document is invalid". AND THEN WHAT? Your only option is to discard it. I'd rather live by the old maxim "be liberal in what you accept, and strict in what you produce". But perhaps I'm overlooking an important u…

Why do you need to be liberal in what you accept, regarding to API? It just invites for subtle bugs. It makes sense for user-generated input, like phone numbers or addresses. But for software? You're encouraging buggy incomplete software that'll bite you or your client one way or another with that liberal approach. API must be absolutely strict and unambiguous. It helps everyone in the end. Or you'll end up with pars…

> This already helps to eliminate lots of unnecessary code.

Well, I think you just moved the validation code to another place. Instead of putting it in your app, where (in my opinion) it belongs, you are putting it in a hard-to-read and difficult to understand external JSON file. I'm not sure how that's an improvement.

Re: JSON Schema bundling formalised

#88

Post by staticassertion »

oaiey wrote: post #77
dgb23 wrote: post #68

Earlier quoted context omitted.

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…

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.

Re: JSON Schema bundling formalised

#89

Post by dolmen »

Bundling for OpenAPI specification has long been a need for authors to allow to reduce duplication, and to allow to split a big specification in multiples files, but publish a single one.

A few years ago I've written a tool to fit that niche: https://github.com/dolmen-go/openapi-preprocessor

https://github.com/dolmen-go/openapi-preprocessor

I have now to tweak it (well, it will be a major rewrite) to handle $ref relative to $id instead of the file location.

Re: JSON Schema bundling formalised

#90

Post by IggleSniggle »

panzerklein wrote: post #47
diegoperini wrote: post #36

I haven't stumbled upon a better schema for JSON than the Typescript definition files. If only I could use them in non Typescript contexts. https://www.typescriptlang.org/docs/handbook/declaration-fil...

You can write validation schemas using zod library [1]. They end up looking pretty similar to typescript definitions (same vocabulary, same methods for combining/intersecting/filtering). And if you migrate to typescript you'll get type definitions for free out of those schemas. [1] https://github.com/colinhacks/zod

If you like zod, you should check out myzod: https://github.com/davidmdm/myzod
Post reply on HN