raml-spec

Taking this concept further one could model in RAML [0] to define both the types (flat or nested) and api definitions. It's based on YAML 1.2 with enough maturity to provide capabilities such as union types, extensions, includes, user-defined facets, etc. The AMF project [1] can be used to parse and transform to/from RAML, OpenAPI, GraphQL, and json schema. Code generation to languages of choice can be bolted on from there. I'm using this approach to define canonical data models. Subsequent code generation scaffolds internal application integration apis, master data management (MDM) entities, and SQL/OLAP artifacts for ETL / BI purposes. This approach keeps overall end-to-end data architecture consistent, in sync, and versioned under source control. Additionally, flat types as required by relational systems are re-used and composed into n

> Do you use JSON Schema? At one point I did, but then discovered RAML[0] and it subsumed the value of what JSON Schema provides as well as being easier to work with than OpenAPI[1]. Also, generating JSON Schema from RAML definitions has proven to be a fairly straightforward process. The usual caveats apply... Your mileage may vary, my experiences do not speak for any others, my opinion does not detract from the value of JSON Schema, etc. 0 - https://github.com/raml-org/raml-spec/blob/master/versions/r... 1 - https://swagger.io/specification/