Ask HN: Is anyone using json schema? | Hacker News Reader

Ask HN: Is anyone using json schema?

14 pointsluney17 comments

I am building a JSON editor/viewer that conforms to a schema. It is sort of like a non developer friendly way to edit or view documented JSON. The best resource i've found for any kind of existing JSON schema standard is at http://json-schema.org

Either I have not been paying attention or I have not seen many API's or other JSON related software using any kind of schema for reference or validation.

I'm curious as to the pulse of who's adopted or found using a JSON schema useful or if it has been largely ignored and we're doing just fine without it.

View on HN

Your phrase:

> largely ignored and we're doing just fine without it

is a pretty good description of how it's going here. Let be be a bit more specific. We used to build lots of SOAP services, and maintaining the schemas that clearly specified the interface was a real effort. When we moved to APIs that used JSON, at first we did little in the way of documentation - and as usual, doing no documentation worked fine at first.

After the JSON API use grew to on the order of 300 developers in teams across the country "no documentation" didn't scale so well. Instead, we've been using swagger specifications to document our APIs. First of all, the swagger specification is far less detailed and precise than the XML schema were. Secondly, my observation (not carefully measured) is that only about 80-90% of the swagger specifications are even accurate. And no one cares. Apparently the level that works for us is just slightly above "no documentation" but well below "clear and accurate specifications".

And I'm (mostly) OK with that.

My experience is similar, but using RAML instead of Swagger. RAML has built-in support for JSON Schema.

I suppose the use case is somewhat similar to XSD, but this is more intuitive and way less verbose. There's also immediate value in using it to parameterize resource types to stay DRY when you use the same resource across multiple endpoints.

I think of it more for templating than validation.

http://raml.org/developers/raml-200-tutorial#extract-schemas

Someone here tried it but we quickly gave up on it.

- It's ugly and borderline impossible to write by hand because it's JSON. To document something complex your JSON objects get 20 layers deep and you don't get any decent commenting.

- Because it's so hard to read, it's useless by itself as a guide to how the JSON should be structured.

- Someone would change the code and always forget to update the schema to match. It only makes sense if you're somehow generating the code from the schema.

> - Someone would change the code and always forget to update the schema to match. It only makes sense if you're somehow generating the code from the schema.

We used http://www.jsonschema2pojo.org/ (via the gradle plugin) on a previous project. I think it worked fairly well.

Composer uses JSON schema to validate composer.json files. See https://github.com/composer/composer/blob/master/res/compose...

It's just the equivalent of an XSD. A lot of people use XML without an XSD. I think it's perfectly fine to not use JSON schema if you don't want to, but having it gives you an easy path toward validating user-generated JSON. It's a nice-to-have.

The Vega Visualization Grammar [1] is encoded using JSON Schema. However, I think there are some bugs in the grammar that can be attributed to the (IMHO) clumsiness of JSON schema.

If you are looking for a good JSON editor that respects JSON schema to compare with your implementation, try Visual Studio Code [2].

[1] http://vega.github.io/

[2] https://code.visualstudio.com/download

I've used it for a few small tools and love it. I started out just writing schemas for testing the format of JSON generated by tools or pulled from an API, but you can do so much more... like using it to generate documentation or even [create forms](https://github.com/joshfire/jsonform).

We're using it at GoCardless to generate reference docs for our recurring payments API. https://developer.gocardless.com/2015-07-06/#overview

A while back I wrote jsonmerge, a Python library for merging series of JSON documents. The syntax it uses for specifying merging rules is based on JSON schema:

https://pypi.python.org/pypi/jsonmerge

Blog post with some background:

https://www.tablix.org/~avian/blog/archives/2014/08/jsonmerg...

We are using it at my current place of work with https://github.com/jdorn/json-editor to generate simple administrative UIs for backing configurations for non-technical users.

It's not a fantastic UX but it works and it's fast to develop.

The docs are sparse but for my money the format is relatively intuitive. I'd prefer to be using XML/XSL/XSLT as they are FAR more powerful, but that's just what you get with JSON.

At a previous job (huge enterprise dev org of 1000+ devs, many many siloed teams) we used it for client-side validation of rest service calls.. it was a really easy way of detecting missing/bad data from upstream systems and handling it appropriately.

It was also great for contract testing in CI of other teams' services (warning us if they slipped some breaking change into the build).

We are using it in production for more than a year. Primarily to define schema for jobs that process terabytes of data on cloud, on-demand.

We adopted it in the SpeedTracer chrome plugin a while back. We were very happy with the results then. Though, for the stuff I've been working with lately most JSON APIs are defined by protos, and we just bridge with JsonFormat/ProtoTypeAdapter

Json-LD is getting training traction here and there.

JSON-LD is not for validation - it's for linked data

You can use it more than one way. That's what linked data is all about.

Here you can find JSON schema http://testingalert.com/api-testing/api-automation/

Reply on news.ycombinator.com