41–50 of 188 posts
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...
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...
> "Developers of platforms and libraries that use OpenAPI haven't had such a shake up before, and my feeling is it may take more than a few releases to correctly implement all the new shiny features full JSON Schema has to offer."
Dear OpenAPI, please avoid the shiny features.
I generally prefer using JSON in my interactions, where possible. That's because it is lightweight, and 99.9% of the data I'm transferring is scalar. JSON is basically "implied" for scalar types. The good thing (if you want to call it "good") about XML, is Schema. Schema is a "rock hard" contract. It is definite, empirical, unambiguous. When I am looking at an API, and it has a Schema, then I know that I can figure o…
One thing I'm guilty of is designing a document format as JSON, thus the need to formally verify it. Passing data works well as JSON but documents works better as XML where you can use XML Schema.
Even though JSON is a "natural" for scalar types, it can get weird, there. For example, let's say we have a float:
{ "kids": 1.0 }
{ "kids": 2.3 }
{ "kids": 1 }
{ "kids": "1.0" }
{ "kids": "1" }
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…
You trust the memory manager, the SSL library and countless others to do their jobs, data validation is no different.
Whether a particular library is up to scratch, is, ofcourse, debatable.
Any library worth it's salt, like asp.net, allows you to define custon data type, like SKU, with whatever validation your heart desires.
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...
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…
API must be absolutely strict and unambiguous. It helps everyone in the end. Or you'll end up with parseInt abomination.
And for strict API you need strict validation. Probably better than schema can provide, but schema is a good start with declarative description and proven battle-tested libraries. After request was validated by the schema, you can be sure in some facts, like which properties are not null, which values are numbers and so on. This already helps to eliminate lots of unnecessary code.
But what's wrong with just stuffing the schemas in a flat array or object exactly?
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…