json-schema-spec VS json-api

Assume that you get the following JSON schema specification:

The outcome of my research was that there weren't really any good libraries for dealing with JSON Schema from within Haskell. That was a surprising disappointment, because Haskell often has very good libraries (although they may be hard to use). The reason is that the JSON Schema specification itself isn't very well-made.

{ "$schema": "https://json-schema.org/draft/2020-12/schema", "$id": "https://upsidelab.io/recipe.schema.json", "title": "Recipe", "description": "A recipe definition", "type": "object", "properties": { "ingredients": { "description": "The list of ingredients required to prepare the recipe", "type": "array", "items": { "$ref": "#Ingredient" } }, "steps": { "description": "The list of steps required to prepare the recipe", "type": "array", "items": { "$ref": "#Step" } } }, "$defs": { "ingredient": { "$anchor": "Ingredient", "type": "object", "properties": { "id": { "type": "number" }, "name": { "type": "string" }, "quantity": { "type": "string" } } }, "step": { "$anchor": "Step", "type": "object", "properties": { "id": { "type": "number" }, "name": { "type": "string" }, "description": { "type": "string" }, "dependsOnSteps": { "type": "array", "items": { "type": "number" } }, "dependsOnIngredients": { "type": "array", "items": { "type": "number" } } } } } }

While there are variety of JSON schema tools since the introduction of JSON schema, this project is focused on the following:

JSON Schema: The industry standard for defining and validating JSON data structures.

The framework's official website mentions a number of pros of FastAPI. In my opinion, the most useful features from a microservice perspective are: the simplicity of code (easy to use and avoid boilerplate), high operational capacity thanks to Starlette and Pydantic and compatibility with industry standards - OpenAPI and JSON Schema.

2. schema ⇾ (optional) you can provide it a JSON schema (https://json-schema.org/) in which you define the wanted output.

I needed it myself and thought it might be fun to create a little tool out of it.

Best

As of OpenAPI 3.1, you can additionally embed JSON Schema directly into your definition, which tooling takes advantage of to generate documentation and perform contract testing.

For our data model we started with https://jsonresume.org/ but needed to adapt a bit.

Ideally there would be something on https://json-schema.org/ (as there are for industry job posting standards)

Why reinvent the wheel poorly when you have a hundred of solutions like https://jsonapi.org/?

For context, the subject-predicate-object pattern is known as a semantic triple or Resource Description Framework (RDF) triple:

https://en.wikipedia.org/wiki/Semantic_triple

They're useful for storing social network graph data, for example, and can be expressed using standards like Open Graph and JSONAPI:

https://ogp.me

https://jsonapi.org

I've stored RDF triples in database tables and experimented with query concepts from neo4j:

https://neo4j.com/docs/getting-started/data-modeling/tutoria...

These are straightforward to translate to SQL but the syntax can get messy due to not always having foreign keys available and hitting limitations with polymorphic relationships. Some object-relational mapping (ORM) frameworks help with this:

https://laravel.com/docs/12.x/eloquent-relationships#polymor...

I feel that document-oriented databases like MongoDB jumped the gun a bit, and would have preferred to have had graph-oriented or key-value-oriented databases providing row/column/document oriented queries and views. Going the other way feels a bit kludgy to me:

https://www.mongodb.com/resources/basics/databases/mongodb-g...

Basically Set Theory internally with multiple query languages externally and indexed by default.

Oh and have all writes generate an event stream like Firebase does so we can easily build reactive apps.

Built on JSON API standards, the OSF API is intuitive for anyone familiar with REST conventions. Once you learn its core patterns, you can quickly expand into project creation, user collaboration, and more—without constantly referencing documentation. The official OSF API docs provide everything needed to get started.

Following established patterns reduces the learning curve for your API. Adopt conventions from JSON:API or Microsoft API Guidelines to provide consistent experiences.

I’ve used both GraphQL and REST in the past. From json:api to Relay, each approach for building APIs has its pros and cons. However, a constant challenge is choosing between code-first and schema-first approaches.

Features: REST-like CQRS HTTP-API, Faceted Search, Full-text Search Interface: OpenAPI, JSON, JSON API, JSON Schema Query Languages: SQL dialect, Cypher, Gremlin, MQL, GraphQL Ingest Protocols: OAI-PMH, S3 Ingest Encoding: XML Ingest Formats: DataCite, DublinCore, MARC, MODS Deployment: Compose, Docker-Compose, Podman-Compose, K8s (via Kompose) Components: ArcadeDB, Connect, Lowdefy License: MIT

There is a group of people who set out to standardize JSON responses into a single response style, either for returning single or multiple resources. You can take their style as a reference when designing their API to ensure uniformity of responses.

The server seems to be using the popular JSON:API standard which is a great way to build APIs. But should we really use these data structures in the frontend?

Note: You think the response data structure with the data field and the included field with mixed data types looks weird? You might not have encountered the popular JSON:API standard yet.