Make collection propertie render as relation instead of property in json HAL representaion - spring-data-rest

I got hal formatted response as this:
{
"name": "Publisher A",
"bookPublishers": [
{
"publishedDate": "2019-07-12T08:19:04.583+0000",
"_links": {
"publisher": {
"href": "http://localhost:8080/api/publishers/1"
},
"book": {
"href": "http://localhost:8080/api/books/2"
}
}
},
{
"publishedDate": "2019-07-12T08:19:04.564+0000",
"_links": {
"publisher": {
"href": "http://localhost:8080/api/publishers/1"
},
"book": {
"href": "http://localhost:8080/api/books/1"
}
}
}
],
"_links": {
"self": {
"href": "http://localhost:8080/api/publishers/1"
},
"publisher": {
"href": "http://localhost:8080/api/publishers/1"
},
"friends": {
"href": "http://localhost:8080/api/publishers/1/friends"
},
"createdBy": {
"href": "http://localhost:8080/api/publishers/1/contact"
}
}
}
I see there property bookPublishers and also in links friends. Imho they should be both association links (see 2.4. Creating the Associations) where can I "put" another resources.
I would like to make spring render bookPublishers same as friends.
Sample project is here: https://github.com/luvarqpp/poc-springHalRelations
You can do:
git clone https://github.com/luvarqpp/poc-springHalRelations.git
cd poc-springHalRelations
mvn clean spring-boot:run
And than open http://localhost:8080/api
PS: Bonus question, what is easiest way to provide own relation for business logic, like relation "renameAuthor" for example.

For collection relationships, Spring Data will provide a link when a repository exists for the relevant type. Where no repository exists then the collection will be in-lined in the response, otherwise, how else will the client get the data.
Therefore, create a repository for your BookPublisher type.
Relevant documentation part citation:
the component responsible for creating the links to referenced entities (such as those objects under the _links property in the object’s JSON representation). It takes an #Entity and iterates over its properties, creating links for those properties that are managed by a Repository and copying across any embedded or simple properties.
You can also create a projection that would in-line the data when required. Clients could specify this projection in the request therefore preventing an additional server call.
e.g.
/publisher/1?projection=withBookPublishers.
https://docs.spring.io/spring-data/rest/docs/current/reference/html/#projections-excerpts.projections

Related

NJson Schema additional property without Attribute

I'm using NJsonSchema to create json shema from my backend to API UI.
I would like to add some customer properies to each properies of backend classıs. I know there is an attribute ([JsonSchemaExtensionData("description", "FirstName")]) whicj is working as expected. But I don't wanna do this for every single POCO classes and attributes.
What I want to do is showen in the below.For this example I wanna add "description": "FirstName" to every properties of my classes.
"$schema": "http://json-schema.org/draft-04/schema#", "title": "Person", "type": "object", "additionalProperties": false, "properties": {
"FirstName": {
"type": [
"null",
"string"
],
"description": "FirstName"
},
And I have seen an another (custom shema processor) solution which is looks like better way. But I don'y know how to implement .
Unfortunately unable to find fully working code sample.
public class MySchemaProcessor : ISchemaProcessor
{
public void Process(SchemaProcessorContext context)
{
// Don't know what to do here ??
}
}

How do I subclass a JSON schema

How do I subclass in JSON-Schema?
First I restrict myself to draft-07, because that's all I can find implementations of.
The naive way to do sub-classing is described in
https://json-schema.org/understanding-json-schema/structuring.html#extending
But this works poorly with 'additionalProperties': false?
Why bother with
additionalProperties': false?
Without it - nearly any random garbage input json will be considered valid, since all the
'error' (mistaken json) will just be considered 'additionalProperties'.
Recapping https://json-schema.org/understanding-json-schema/structuring.html#extending
use allOf(baseClass)
then add your own properties
The problem with this - is that it doesn't work with 'additionalProperties' (because of
unclear but appantly unfortunate definitions of additionalProperties that it ONLY applies
to locally defined (in that sub-schema) properties, so one or the other schema will fail validation.
Alternative Approaches:
meta languages/interpretters layered on top of JSONSchema
(such as https://github.com/mokkabonna/json-schema-merge-allof)
This is not a good choice as the scehma can only be used from javascript (or the
language of that meta processor). And not easily interoperable with other tools
https://github.com/java-json-tools/json-schema-validator/wiki/v5%3A-merge
An alternative I will propose as a 'solution' / answer
How do I subclass in JSON-Schema?
You don't, because JSON Schema is not object oriented and schemas are not classes. JSON Schema is designed for validation. A schema is a collection of constraints.
But, let's look at it from an OO perspective anyway.
Composition over inheritance
The first thing to note is that JSON Schema doesn't support an analog to inheritance. You might be familiar with the old OO wisdom, "composition over inheritance". The Go language, chooses not to support inheritance at all, so JSON Schema is in good company with that approach. If you build your system using only composition, you will have no issues with "additionalProperties": false.
Polymorphism
Let's say that thinking in terms of composition is too foreign (it takes time to learn to think differently) or you don't have control over how your types are designed. For whatever reason, you need to model your data using inheritance, you can use the allOf pattern you're familiar with. The allOf pattern isn't quite the same as inheritance, but it's the closest you're going to get.
As you've noted, "additionalProperties": false wreaks havoc in conjunction with the allOf pattern. So, why should you leave this out? The OO answer is polymorphism. Let's say you have a "Person" type and a "Student" type that extends "Person". If you have a Student, you should be able to pass it to a method that accepts a Person. It doesn't matter that Student has a few properties that Person doesn't, when it's being used as a Person, the extra properties are simply ignored. If you use "additionalProperties": false, your types can't be polymorphic.
None of this is the kind of solution you are asking for, but hopefully it gives you a different perspective to consider alternatives to solve your problem in different way that is more idiomatic for JSON Schema.
I struggled with that, especially since I had to use legacy versions of JSON Schema. And I found that the solution is a tiny bit verbose but quite easy to read and understand.
Let's say that you want describe that kind of type:
interface Book {
pageCount: number
}
interface Comic extends Book {
imageCount: number
}
interface Encyclopedia extends Book {
volumeCount: number
}
// This is the schema I want to represent:
type ComicOrEncyclopedia = Comic | Encyclopedia
Here is how I can both handle polymorphism and forbid any extra-prop (while obviously enforcing inherited types in the "child" definitions):
{
"$schema": "http://json-schema.org/draft-07/schema#",
"definitions": {
"bookDefinition": {
"type": "object",
"properties": {
"imageCount": {
"type": "number"
},
"pageCount": {
"type": "number"
},
"volumeCount": {
"type": "number"
}
}
},
"comicDefinition": {
"type": "object",
"allOf": [{ "$ref": "#/definitions/bookDefinition" }],
"properties": {
"imageCount": {},
"pageCount": {},
"volumeCount": {
"not": {}
}
},
"required": ["imageCount", "pageCount"],
"additionalProperties": false
},
"encyclopediaDefinition": {
"type": "object",
"allOf": [{ "$ref": "#/definitions/bookDefinition" }],
"properties": {
"imageCount": {
"not": {}
},
"pageCount": {},
"volumeCount": {}
},
"required": ["pageCount", "volumeCount"],
"additionalProperties": false
}
},
"type": "object",
"oneOf": [
{ "$ref": "#/definitions/comicDefinition" },
{ "$ref": "#/definitions/encyclopediaDefinition" }]
}
This isn't a GREAT answer. But until the definition of JSONSchema is improved (or someone provides a better answer) - this is what I've come up with as workable.
Basically, you define two copies of each type, the first with all the details but no additionalProperties: false flag. Then second, REFERENCING the first, but with the 'additionalProperties: false' set.
The first you can think of as an 'abstract class' and the second as a 'concrete class'.
Then, to 'subclass', you use the https://json-schema.org/understanding-json-schema/structuring.html#extending approach, but referencing the ABSTRACT class, and then add the 'additionalProperties: false'. SADLY, to make this work, you must also REPEAT all the inherited properties (but no need to include their type info - just their names) - due to the sad choice for how JSONSchema draft 7 appears to interpret additionalProperties.
An EXAMPLE - based on https://json-schema.org/understanding-json-schema/structuring.html#extending should help:
https://www.jsonschemavalidator.net/s/3fhU3O1X
(reproduced here in case other site
/link not permanant/reliable)
{
"$schema": "http://json-schema.org/draft-07/schema#",
"$id": "https://TEST",
"definitions": {
"interface-address": {
"type": "object",
"properties": {
"street_address": {
"type": "string"
},
"city": {
"type": "string"
},
"state": {
"type": "string"
}
},
"required": ["street_address", "city", "state"]
},
"concrete-address": {
"allOf": [
{
"$ref": "#/definitions/interface-address"
}
],
"properties": {
"street_address": {},
"city": {},
"state": {}
},
"additionalProperties": false
},
"in-another-file-subclass-address": {
"allOf": [
{
"$ref": "#/definitions/interface-address"
}
],
"additionalProperties": false,
"properties": {
"street_address": {},
"city": {},
"state": {},
"type": {
"enum": ["residential", "business"]
}
},
"required": ["type"]
},
"test-of-address-schemas": {
"type": "object",
"properties": {
"interface-address-allows-bad-fields": {
"$ref": "#/definitions/interface-address"
},
"use-concrete-address-to-only-admit-legit-addresses-without-extra-crap": {
"$ref": "#/definitions/concrete-address"
},
"still-can-subclass-using-interface-not-concrete": {
"$ref": "#/definitions/in-another-file-subclass-address"
}
}
}
},
"anyOf": [
{
"$ref": "#/definitions/test-of-address-schemas"
}
]
}
and example document:
{
"interface-address-allows-bad-fields":{
"street_address":"s",
"city":"s",
"state":"s",
"allow-bad-fields-this-is-why-we-need-additionalProperties":"s"
},
"use-concrete-address-to-only-admit-legit-addresses-without-extra-crap":{
"street_address":"s",
"city":"s",
"state":"s"
},
"still-can-subclass-using-interface-not-concrete":{
"street_address":"s",
"city":"s",
"state":"s",
"type":"business"
}
}

How do you extend json schema meta schema to support new properties?

I want to allow a $role properties anywhere in a json schema document where type is allowed. In theory I should be able to extend it as below where I do allOf against both the json schema meta-schema and my extension for $role which includes additionalProperties to pick up my extension meta-schema recursively. What I find is that I get validation for a top-level $role, but not for any embedded one. Am I missing something? Is there some other way I should extend the JSON Schema meta-schema?
I've tried a bunch of different validators and they all fail at validating the second $role in the example.
{
"$schema": "http://json-schema.org/draft-07/schema#",
"definitions": {
"role": {
"type": "string",
"pattern": "^((lg)|(unionType\\([a-zA-Z][a-zA-Z0-9.]*\\)))$"
},
},
"allOf": [
{
"$ref": "http://json-schema.org/draft-07/schema#"
},
{
"properties": {
"additionalProperties": {
"$ref": "#"
},
"$role": {
"oneOf": [
{
"$ref": "#/definitions/role"
},
{
"type": "array",
"items": {
"$ref": "#/definitions/role"
}
}
]
}
}
}
]
}
Example using this schema:
{
"$schema": "schema.json",
"title": "Prompt",
"$role": "unionType(Microsoft.IPrompt)",
"properties": {
"prompt": {
"type": "string",
"$role":"foo"
}
}
}
What I expect is that the second role should be invalid according to the schema. What I get is that it is valid even though it does not match the $role pattern. The first $role does validate successfully.
Yep, extending a meta schema is more complicated than it seems. Checkout the the JSON Hyper-Schema meta schema for an example of how to extend a meta schema. JSON Hyper-Schema adds two keywords: base and `links. When extending a schema, you need to redefine any recursive reference used in the original schema.
JSON Schemas (including meta-schemas) are immutable. You can't selectively modify an existing schema. Your meta schema only validates the $role keyword, all other keywords are validated by the draft-07 meta schema. Because your meta schema doesn't modify the draft-07 schema, keywords like properties are validated entirely within the context of the draft-07 schema and without knowledge of the new keyword you added in another schema.
It's unfortunate that so much duplication is involved in extending schemas and it is a problem that is being worked on. A potential solution to make this easier is slated to be introduced in the next draft.

How to define a related resource URI in JSON:API

In the json:api format relationships are defined with a type and a id.
Like in the example bellow. The article has a relationship with the type people and the id 9.
Now if i want to fetch the related resource i use the URI from "links.related"
// ...
{
"type": "articles",
"id": "1",
"attributes": {
"title": "Rails is Omakase"
},
"relationships": {
"author": {
"links": {
"self": "http://example.com/articles/1/relationships/author",
"related": "http://example.com/articles/1/author"
},
"data": { "type": "people", "id": "9" }
}
},
"links": {
"self": "http://example.com/articles/1"
}
}
// ...
But in my case the related resource (people) are in a separate API. There is no way to get the full people data from the articles API nor is it possible to include it. The only way to get the related data would be a call to:
http://example.com/v1-2/people/9/
Where can i define the relation between the URI and people:9
Or in other words: How would a client know where to fetch the related resource?

Is this API structure HATEOAS compatible?

I'm wondering if the following structure of API links is HATEOAS compatible?
Especially I'm not sure of /create endpoint. Should it be at the entry level because user can create a group from there or is it fine to put it in /groups?
What are your thoughts about the rest? It should be also HAL compatible.
/groups
/create
/detail/{groupId}
/update
/delete
/items
/search{?page,size,sort}
HATEOAS (see Richardson's Maturity Model level 3) is all about links, so with HAL Browser this would look something like this:
Root:
{
"_links": {
"self": {
"href": "/api/root"
},
"api:group-add": {
"href": "http://apiname:port/api/group"
},
"api:group-search": {
"href": "http://apiname:port/api/group?pageNumber={pageNumber}&pageSize={pageSize}&sort={sort}"
},
"api:group-by-id": {
"href": "http://apiname:port/api/group/id" (OR "href": "http://apiname:port/api/group?id={id}")
}
}
}
The add would simply be a POST to that endpoint, and then you'd have 2 GET methods.
Then once you drill down to a particular group (say #1):
{
"Id" : 1,
"Name" : "test",
"_links": {
"self": {
"href": "/api/group/1" (OR "/api/group?id=1")
},
"edit": {
"href": "http://apiname:port/api/group/1"
},
"api:delete": {
"href": "http://apiname:port/api/group/1"
},
"api:items-query": {
"href": "http://apiname:port/api/bonus?groupId=1"
}
}
}
Here, the edit would simply be a PUT, and then you'll need a DELETE (see level 2 of REST in that same link), as for the items, you probably know best if they are just a property, or another endpoint; you could even embed them to be returned in the same call that's retrieving a group.