111–120 of 188 posts
> "There are several libraries which offer bundling solutions, however they all have caveats, and I haven't seen any to date which are fully JSON Schema aware." But what's wrong with just stuffing the schemas in a flat array or object exactly?
Would be good if there was a clear statement about who the authors are and what makes their content authorative.
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.
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…
back to CORBA
It's just riddled with features.
Earlier quoted context omitted.
Neither is 'non negative' - but that should also be a built-in, considering how verbose the language becomes otherwise. Now you're adding ~5 lines of boilerplate every time you want to have an integer, another 5 for positive integers, and so on.
To support non-negative integers, all you need is the following {"type": "integer", "minimum": 0} I think the format used in the example was used to demonstrate bundling, but if what you really want is a non-negative integer, the above is the simplest way to do it.
If I had used a more complex example, it would have been much harder to follow. This was the simplest.
We factor this out for our meta-schema construction due to reuse.
Earlier quoted context omitted.
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.
Also, I can replicate my validations at many levels down the stack: from the client to API-GW to the database model. All with a single definition.
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…
> The only fundamental advantage that I would give XML over JSON is the fact that you can encode meta data in XML in a more idiomatic, standard way via attributes. But we all know that is not how XML is being used. If the ecosystem around XML wasn't abusing attributes to encode core/primary data, then there would be a stronger argument for the language IMO. Attributes are absolutely one of the reasons for XML's failu…
I imagine if there was discipline around attributes being only used for meta-data and maybe explicit (de-normalized) references (which is arguably meta data, happy to discuss), then XML would be semantically richer by default. However like this we are left guessing the semantics if we encounter some XML.
Somewhat in contrast, HTML is generally, but not consistently, better at making this distinction, which enables clearer semantics around accessibility, HATEOAS and so on. Ironically we are kicking that value proposition into the can when driving web application rendering with JSON (like popular SPA frameworks do), so we have to re-invent meta data and communicate that with JSON-schema.
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…
> 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?
The point of JSON Schema (and schemas for serialization format in general) is to have a machine readable description of the data constraints that both a writer of the data and a reader of that data can use to automate both validation and documentation rendering.
> 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.
Do you trust the compiler/runtime of your programming language?
JSON Schema can allow to use a JSON Schema definition for translation into validation code. That may not fit all crazy validation rules, but at least that allow to automate one validation layer from a specification.
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.
At my company, we found that the auto-OAS generation tools were too brittle and didn't communicate enough information, so we actually do write our own OAS and run automation to make sure it's accurate.
That's also how our architects communicate with developers about an endpoint - create an OAS for it.
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…
I feel exactly the same. I also want to add that consumers with an appropriate framework can automatically generate a response body explaining where in the payload that errors were encountered and what those errors are. This allows API consumers to understand what is going wrong far more easily that a 500 being returned. ASP.NET for example can do exactly this with validation on incoming payloads. If the payload is i…