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

141–150 of 188 posts

Re: JSON Schema bundling formalised

#141

Post by theamk »

xienze wrote: post #130
paulddraper wrote: post #79

Earlier quoted context omitted.

And that's the issue. SOAP isn't some nice standardized language-agnostic API layer. SOAP is .NET/Visual Studio RPC. (Not technically, but in practice, due to its complexity.) And hey, great for you. But a lot of people want APIs to be broadly compatible.

> SOAP isn't some nice standardized language-agnostic API layer. What? Of course it is (well, it's a messaging protocol). Where on earth did you get the idea that it's some Microsoft-only proprietary technology?

You missed the word "nice" in the GP's message. Also "(Not technically, but in practice, due to its complexity.)"

No one says it is proprietary technology and yes, it is nominally standardized. It is just so complex that it is impossible to use without heavy tooling support, and this tooling is only really usable in Microsoft's technology.

So it seems that people who use MS ecosystem like SOAP ... while almost everyone else who tried it calls is over-complicated, incomprehensible and "worst dev experience of my whole career"

Re: JSON Schema bundling formalised

#142

Post by SV_BubbleTime »

espadrine wrote: post #133
arethuza wrote: post #71

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.

One thing I am wondering is whether the protobuf folks have a better development environment overall, or a worse one. Is the schema-to-self-validating-serialization-code approach going to win just as JSON won over XML?

This is what I was thinking, but no, skeptical. Protobufs are far more efficient, but dump the human readability for the data transfer, and that is where the logging and debugging happen quite a bit.

As to code generation, if you use someone’s package for confirm_my_schema(thisjson) isn’t that basically code generation just moved somewhere else?

Re: JSON Schema bundling formalised

#143

Post by run-types »

move-on-by wrote: post #132
run-types wrote: post #97

For those looking to sanitize input from Typescript, I highly recommend the runtypes library: https://github.com/pelotom/runtypes It let's you specify type definitions a DSL in Typescript using syntax very similar to Typescript's type definitions. Once you define your types in the DSL, you get Typescript types and parsing / verification for free. Not as general purpose as JSON Schema, but 1000x cleaner and easier to…

I've never seen runtypes, but I've seen io-ts [1]. Are you aware of the pros/cons between them? [1] https://gcanti.github.io/io-ts/

They look roughly the same

Re: JSON Schema bundling formalised

#145

Post by HelloNurse »

matja wrote: post #73
Someone wrote: post #62

Earlier quoted context omitted.

That’s not an issue with json, but with json libraries. For better or (IMO) for worse {“kids”: 12345678901234567890123456789012345678901234567890} is perfectly legal json.

If every JSON library actively chooses not to implement the JSON spec, that sounds like an issue with JSON to me.

More precisely, an issue with different literal types instead of one like in XML.

In XML, every attribute or text fragment is a string, to be POSSIBLY parsed as a string, integer, date etc. according to what applications choose to do (usually according to an explicit schema).

In JSON, YAML, etc. there are at least integers, strings and floating point numbers, introducing arbitrary representation choices (1, 1.0, "1", "1.0") and implementation artifacts (e.g. numerical limits).

Re: JSON Schema bundling formalised

#146

Post by xienze »

theamk wrote: post #141
xienze wrote: post #130

Earlier quoted context omitted.

> SOAP isn't some nice standardized language-agnostic API layer. What? Of course it is (well, it's a messaging protocol). Where on earth did you get the idea that it's some Microsoft-only proprietary technology?

You missed the word "nice" in the GP's message. Also "(Not technically, but in practice, due to its complexity.)" No one says it is proprietary technology and yes, it is nominally standardized. It is just so complex that it is impossible to use without heavy tooling support, and this tooling is only really usable in Microsoft's technology. So it seems that people who use MS ecosystem like SOAP ... while almost everyo…

> It is just so complex that it is impossible to use without heavy tooling support, and this tooling is only really usable in Microsoft's technology.

Again, gotta call BS here. My early career was 100% SOAP and related WS-* technologies. And it was all in Java, Apache Axis and friends. Wildly popular at the time. Give it your WSDL, out pops a nice Java client. People didn’t like it not because it was difficult to use outside of the Microsoft ecosystem, they didn’t like it because it was the concepts were difficult to understand and there were many complicated technologies piggybacking off of it. It was hard to debug issues, Visual Studio or not. If you had to do something that a generated client could do, it was difficult, Visual Studio or not.

Re: JSON Schema bundling formalised

#147

Post by diroussel »

radomir_cernoch wrote: post #131
oaiey wrote: post #103

Earlier quoted context omitted.

Parsing XML is just grammar like JSON is ... that is not more or less difficult. JavaScript just has a built-in JSON Parser (which translate JSON into JavaScript object). 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, JSO…

In can't agree more. In Java, there's the JAXB ”parser“ which translates an XML schema into (mostly) straightforward classes. Correct initial setup is the only hard part.

The key difference is that there are no options when you parse json. You just parse it and get some lists and maps back.

In XML you have to decide if you want DTD or schema enabled (which could provide default values, and could be a security risk) and where abs how you resolve the DTDs from etc. Do you resolve references? And many option options.

So JSON benefits not just from a simpler structure, but also from less optionality.

Re: JSON Schema bundling formalised

#148

Post by da_chicken »

reaperducer wrote: post #28
66fm472tjy7 wrote: post #8

Earlier quoted context omitted.

There are things you cannot accept. What do you do if an order has a negative quantity, if you get a string instead of a number, if a value does not fit in your DB column, etc ? Having this as part of your interface definition, along with generated representations of the possible data in the language your choice[0] and automatic (so you can't forget it) validation that rejects invalid input with HTTP 400 bad request…

What do you do if an order has a negative quantity, if you get a string instead of a number, if a value does not fit in your DB column, etc ? Isn't that all just basic data validation and sanitation that we all do anyway? And wouldn't it still have to be done, even if the JSON came with all the schemabloat? I don't think I'm suddenly going to accept that the data presented to my function is valid and fit for purposes…

> I don't think I'm suddenly going to accept that the data presented to my function is valid and fit for purposes just because it goes through someone's JSON schema library. That's just passing the responsibility on to a third party, which feels lazy and dangerous to me.

The purpose of a schema isn't to ensure that every business rule is satisfied. It's just the first step of data validation. It's step 1 of input triage. It's saying, "I'm not even going to look at your input until you can demonstrate that the request meets the minimum requirements of a theoretically valid request."

If I'm asking for a Student, and I say they have to have a StudentId, a FirstName, a LastName, and a DateOfBirth, then I can put that into a schema and immediately reject any submission that tries to submit Surname or GivenName. I can go further and say that StudentId is up to 25 characters and can't be blank. DateOfBirth has to be present, must be a date in yyyy-MM-dd format, and it must be in the past, etc.

You can reject the data as incomplete or invalid at a glance. You're setting up a basic set of rules that allows you to instantly discard a whole range of invalid input.

Re: JSON Schema bundling formalised

#149

Post by ironman1478 »

jonny383 wrote: post #15

If someone tried to push this on my engineering team, they would be laughed out of my office and ridiculed for the idiocy of even suggesting such garbage. The best factor of JSON is being a schema-less, human readable format. Imagine having someone present this monstrosity to you with a straight face, thinking it's a good use for JSON.

So you don't sanitize JSON input to your system? That's what this tool is for. The alternative is writing custom code to validate it, which is just as messy and worse, bespoke.

Re: JSON Schema bundling formalised

#150

Post by ironman1478 »

I started using jsonschema at work and can't go back. We have an extremely large configuration file to configure our system and there are lots of 'optional' blocks that can be configured. Jsonschema really cleanly allows you to express that logic without having to write a line of code. It's been great.

Protip: if you are using jsonschema in python, it takes in a dict() not a file, so you can use yaml (or something else) as your configuration file and still validate it with jsonschema.

Post reply on HN