
Ask HN: Is anyone using json schema? - luney
I am building a JSON editor&#x2F;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&#x27;ve found for any kind of existing JSON schema standard is at http:&#x2F;&#x2F;json-schema.org<p>Either I have not been paying attention or I have not seen many API&#x27;s or other JSON related software using any kind of schema for reference or validation.<p>I&#x27;m curious as to the pulse of who&#x27;s adopted or found using a JSON schema useful or if it has been largely ignored and we&#x27;re doing just fine without it.
======
mcherm
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.

~~~
tedmiston
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](http://raml.org/developers/raml-200-tutorial#extract-schemas)

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

~~~
amrox
> \- 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/](http://www.jsonschema2pojo.org/)
(via the gradle plugin) on a previous project. I think it worked fairly well.

------
cweagans
Composer uses JSON schema to validate composer.json files. See
[https://github.com/composer/composer/blob/master/res/compose...](https://github.com/composer/composer/blob/master/res/composer-
schema.json)

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.

------
harveywi
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/](http://vega.github.io/)

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

------
slang800
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](https://github.com/joshfire/jsonform)).

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

------
avian
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](https://pypi.python.org/pypi/jsonmerge)

Blog post with some background:

[https://www.tablix.org/~avian/blog/archives/2014/08/jsonmerg...](https://www.tablix.org/~avian/blog/archives/2014/08/jsonmerge/)

------
zwerdlds
We are using it at my current place of work with
[https://github.com/jdorn/json-editor](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.

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

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

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

------
PaulHoule
Json-LD is getting training traction here and there.

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

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

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

