diff --git a/migration.md b/migration.md deleted file mode 100644 index 45f8859..0000000 --- a/migration.md +++ /dev/null @@ -1,196 +0,0 @@ - -# Migration - -The following list covers all major restrictions to JSON Schema. This should help -to migrate your JSON Schema to TypeSchema. Also please take a look at our [migration -tool](https://typeschema.org/migration/jsonschema) which allows you to automatically -convert a JSON Schema into a TypeSchema. - -## No-Type - -### Invalid - -```json -{ -} -``` - -In JsonSchema it is possible to define no keyword which means every value is -valid. - -### Reasoning - -In TypeSchema every schema must be assigned to a specific type depending on the -used keywords so that a parser knows at least which type is expected. Depending -on the type there are specific keywords possible. - -## Array-Type - -### Invalid - -```json -{ - "type": ["string", "number"], - "minLength": 12 -} -``` - -In JsonSchema it is possible to allow multiple types at the `type` keyword. - -### Reasoning - -In TypeSchema `type` must be a `string` since based on this schema it is -impossible to generate a strongly typed class. To allow different types you -need to explicit use an union type (`oneOf` keyword) - -## Array-Array-Item - -### Invalid - -```json -{ - "type": "array", - "items": { - "type": "array" - } -} -``` - -In JsonSchema it is possible to use every schema as array item. - -### Reasoning - -In TypeSchema it is not possible to use an array as array value. This is done -because this constructs complicates code generators and it is also bad data -design. - -## Null-Type - -### Invalid - -```json -{ - "type": "null" -} -``` - -In JsonSchema it is possible to define the `null` type. - -### Reasoning - -We think that `null` is not a data type but rather an attribute of a type. -Because of that TypeSchema has the `nullable` keyword which can be `true` or -`false` for every type. - -## Mixed-Assertions - -### Invalid - -```json -{ - "type": "string", - "minLength": 12, - "minimum": 12 -} -``` - -In JsonSchema it is possible to define multiple assertions for different types. - -### Reasoning - -Since in TypeSchema you can define only one type, you can also use only the -assertions which are fitting for the type. I.e. `minimum` for the `number` type -or `minLength` for the `string` type but not both. - -## Pattern-Properties - -### Invalid - -```json -{ - "type": "object", - "patternProperties": { - "^S_": { - "type": "string" - }, - "^I_": { - "type": "integer" - } - } -} -``` - -In JsonSchema it is possible to use pattern properties to apply different -schemas based on the key. - -### Reasoning - -In TypeSchema you need to decide between a struct or map. A struct contains -hardcoded properties through the `properties` keyword and a map makes use of the -`additionalProperties` keyword. For the `additionalProperties` keyword every value -must follow the same schema. Code generators can not usefully understand those -properties and we think also that the `patternProperties` keyword promotes -bad data design. - -## Root-Object - -### Invalid - -```json -{ - "type": "object", - "properties": { - "foo": { - "type": "string" - } - } -} -``` - -### Reasoning - -In JsonSchema you can define a root schema at the top level. In TypeSchema we -can only use a `$ref` at the root level to reference a root schema. This is -because we always need a name for every schema and this is the key at the -`definitions` location. The following example shows a valid version: - -### Valid - -```json -{ - "definitions": { - "MyType": { - "type": "object", - "properties": { - "foo": { - "type": "string" - } - } - } - }, - "$ref": "MyType" -} -``` - -## Anyof-Type - -### Invalid - -```json -{ - "anyOf": [{ - "type": "string" - },{ - "type": "number" - }] -} -``` - -In JsonSchema it is possible to use the `anyOf` keyword. In TypeSchema this -keyword does not exist. You can use either `oneOf` or `allOf`. - -### Reasoning - -The `anyOf` keyword is not practical for code generation. The `oneOf` type can -be mapped to a union type and the `allOf` type can be mapped to an intersection -type. diff --git a/www/resources/template/ecosystem.php b/www/resources/template/ecosystem.php index febc94a..eb0c26c 100644 --- a/www/resources/template/ecosystem.php +++ b/www/resources/template/ecosystem.php @@ -9,11 +9,17 @@
The following page lists integrations, projects and libraries related to TypeSchema.
+The following page lists integrations, libraries and other projects related to TypeSchema.
+Name | +GitHub | +Link | +
---|---|---|
Docker | +GitHub | +Docker | +
GitHub Action | +GitHub | +Marketplace | +
Name | +Description | +
---|---|
psx-schema | +A PHP library to parse and validate TypeSchema specifications | +
Name | +Description | +
---|---|
ngx-typeschema-editor | +An Angular component to visual edit a TypeSchema | +
Name | +Description | +
---|---|
TypeHub | +A service to manage and share TypeSchema specifications | +
TypeAPI | +An OpenAPI alternative to describe REST APIs for type-safe code generation | +
SDKgen | +A service to generate client SDKs | +
We are the developers behind Fusio an open source API management - system. We wanted to build an SDK generator for different languages, which builds an SDK based on the - available schema. During this we have experienced the limitations of JSON Schema for code generators. Because of this - we have started to develop TypeSchema. A JSON format which can be easily transformed into code and also other - specification formats.
- -We envision a future where the code generation ecosystem just works. That means a user gets an TypeAPI document and - he is able to use this document to generate high quality code for either client or server implementations.
- -The complete website is also opensource, you can check out our repository - and take a look at the www folder, there is all code related to the website placed. If you want to take a look at the - code generator you can check out the generator repository.
- -You can contact us directly in case you have a question regarding - the project, or you can also take a look at our repository.
- -In our mission to improve code generation we write articles explaining our thoughts and background regarding - TypeSchema and the hole API and code generation ecosystem. If you are interested you can take a look at the following - articles:
-JSON Schema is a constraint system - which is designed to validate JSON data. Such a constraint system is not great for code generation, with TypeSchema - our focus is to model data to be able to generate high quality code.
- -For code generators it is difficult to work with JSON Schema since it is designed to validate JSON data. In JSON
- Schema you dont need to provide any keywords i.e. {}
is a valid JSON Schema which basically allows every
- value and the defined keywords are applied based on the actual data. This means you can interpret a schema only if you
- have also the actual data. A code generator on the other hand needs to determine a concrete type of a schema without
- the actual data.
JSON Schema has many keywords which contain logic like dependencies
, not
,
- if/then/else
which are basically not needed for code generators and really complicates building them. We
- have also explained some pitfalls in our
- migration document.
TypeSchema does not work with JSON pointer. In TypeSchema you reference every type simply by the name i.e.
- Student
. In JSON Schema you need to provide the path i.e. #/definitions/Student
to the
- schema. In TypeSchema you can also reference only local types. If you want to import a remote schema you need to
- explicit declare it via $import
.
This list gives you access to the reference code generator implementation. + To prevent misuse the code generator is protected by recaptcha, if you want to invoke the code generator + programmatically please take a look at the SDKgen project + which offers various integration options like an CLI, GitHub action or REST API. +
This list gives you access to our reference code generator implementation. - To prevent misuse the code generator is protected by recaptcha, if you want to invoke the code generator - programmatically please take a look at the SDKgen project - which offers various integration options like an CLI, GitHub action or REST API. -
- -
TypeSchema has evolved out of the need to build a solid code generator for a Swagger/OpenAPI specification. + During this development process we have experienced problems + and tried to find a way to solve them. At the beginning we had only defined some "stricter" rules for a JSON Schema to make it easier + for code generators but over time this has evolved into a complete separate specification. TypeSchema provides a solid way + to model JSON payload and a great code generator to automatically generate DTOs + to represent this JSON data.
+ + + +If we look at the history of programming
+ +TypeSchema has a specific thought model which fits perfectly with classical OOP languages like Java, C#, PHP or TypeScript. + But it supports also languages like Go, which have a different approach. In this case the generator will try to apply these concepts on + generation so that you can still use them at the specification. For example Go does not support inheritance, in this case the code generator + copies all inherited properties into the structure.
+ +JSON Schema is a constraint system + which is designed to validate JSON data. Such a constraint system is not great for code generation, with TypeSchema + our focus is to model data to be able to generate high quality code.
+ +For code generators it is difficult to work with JSON Schema since it is designed to validate JSON data. In JSON
+ Schema you dont need to provide any keywords i.e. {}
is a valid JSON Schema which basically allows every
+ value and the defined keywords are applied based on the actual data. This means you can interpret a schema only if you
+ have also the actual data. A code generator on the other hand needs to determine a concrete type of a schema without
+ the actual data.
JSON Schema has many keywords which contain logic like dependencies
, not
,
+ if/then/else
which are basically not needed for code generators and really complicates building them.
TypeSchema does not work with JSON pointer. In TypeSchema you reference every type simply by the name i.e.
+ Student
. In JSON Schema you need to provide the path i.e. #/definitions/Student
to the
+ schema. In TypeSchema you can also reference only local types. If you want to import a remote schema you need to
+ explicit declare it via import
.
In case there are problems with the generated code you can always create an issue at our repository.
+ +You can contact us directly in case you have a question regarding + the project, or you can also take a look at our repository.
+ +At the following list you can take a look at example output for each supported programming language.
We provide several tools which can help to migrate from an external specification or generate specific output based on an existing to TypeSchema specification.
+Through this form you can generate a changelog between two TypeSchema versions.
+Through this form you can generate a schema from existing JSON data. It contains also a logic to detect objects of the same type. You should see this as a starting point since you need to add proper names to each type. -
Through this form you can migrate an existing JSON Schema to a TypeSchema. If you see a name like i.e. Inlinec650cd78
this means that there is an anonymous type in your schema, the migration makes this only visible and you should set
a meaningful name for this type.
-
Through this form you can migrate an existing OpenAPI specification to TypeSchema. This allows you to use the OpenAPI spec to generate a client SDK. -