Please log in to watch this conference skillscast.
Defining a JSON Schema for your data enables a number of interesting use-cases. In a client-server scenario, e.g. a RESTful API, the content of the requests and replies can be exactly defined (also see OpenAPI/Swagger). In addition you can easily validate JSON against its JSON Schema to provide users with feedback for their input on the client side or to check data validity on the server side - based on the same definition. The metadata provided by the JSON Schema is also an enabler for many other runtime use-cases such as serialization, form-based UIs or data interchange. At build-time it can be used as a basis for code generation to automatically derive a data API, e.g. in Typescript, or to enable property-based testing.
Of course where there is light there is also shadow, e.g. you are required to define your data and the available tooling to do so is not really great (yet). In this presentation we will provide you with criteria to judge whether JSON Schema could be beneficial for your project or is just too much overhead.
Find out more on JSON schema here.
YOU MAY ALSO LIKE:
JSON Schema - the good, the bad and the ugly
Edgar Mueller
Edgar Mueller is a Software Engineer at EclipseSource Munich, where he works on various Eclipse-based and other open-source projects. In particular he is currently most active in two open-source projects: JSONForms and Play JSON Schema Validator.
Maximilian Koegel
Maximilian Koegel is deeply involved with the Eclipse open-source community where he contributes as project lead and committer in various projects including EMF and EMFForms and as member of the Eclipse Architecture Council. He focuses on pragmatic modeling based on JSON Schema and EMF and its cross-platform application - from Java to JavaScript.