We have a mobile app that accepts input into some fields, formalises them as a JSON document and then sends it to the back-end for processing.

We want to agree on a schema for this document that can be validated and referenced indirectly in both the back-end and the front-end.

One of the motivations is that the input can change depending on the language, so in a different language, although the structure will be the same, the JSON entries will have different values and so we cannot have those hardcoded at either end (but especially at the back-end).

I'm primarily concerned with how such a schema can be represented and how it can be validated at the back-end. Shall I define an interface for it? If so, is there something standardised already that accomplishes this painlessly?

The target back-end language is Python on Django, we're happy to go with any package as long as it does the job.

  • 2
    take at look here: json-schema.org and here: pypi.python.org/pypi/jsonschema. maybe its what you looking for
    – Urban48
    Commented Jan 12, 2017 at 16:26
  • Thanks, I did find this shortly after posting this question but I'm also hoping to get a reply from someone who's actually implemented the above and can share a few tips.
    – Nobilis
    Commented Jan 12, 2017 at 16:38
  • the implementation is trivial as you can see from the examples, and its really depends on the use-case. just run the request json through the json schema validation function at you back end.
    – Urban48
    Commented Jan 13, 2017 at 9:19

2 Answers 2


We use json schema to validate the objects we send around.

In case you have functional dependencies in a schema, in Python, the library allows you to use functions to validate sub-entries. Example: With jsonschema you can validate that both attributes are numbers. With Python you can additionally validate that one number is greater than the other.

Note on architecture: Schemas can reference each other. We put them into a folder including documentation on how to add, remove and standardize attributes. Each commit creates a new Python package but could also generate a JavaScript, Java, ... package.

What I like about this approach:

  • The schemas have a separate place because their job is to ease communication. So, they do not belong into frontend/backend/any code base.
  • The repository is the place of the communication about what the different applications need. Documentation, issues and pull-requests about the communication process are in one place, not split up over all the different sources that communicate with eachother.

You may want to have a look at YAML, RAML and/or OpenAPI. Or if you want even more reading material have a look at the corresponding overview list at wikipedia.

(And yes, I know that JSON is not the same as REST; I'm just taking a guess here what kind of interface is to be described based on the impression that JSON is more commonly favored by those who design Rest interfaces)

  • Thank you, anything REST related is probably outside of the scope of what we want to accomplish, we just want to have a JSON in a particular format that we can standardise and access in an accepted way. I had in mind something like voluptuous but that concerns the back-end only.
    – Nobilis
    Commented Jan 12, 2017 at 15:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.