Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use a $schema instead of type in Object Schema #3

Open
independentid opened this issue Dec 27, 2021 · 0 comments
Open

Use a $schema instead of type in Object Schema #3

independentid opened this issue Dec 27, 2021 · 0 comments

Comments

@independentid
Copy link
Member

*Please provide some basic information describing your suggestion
In 3.2, provider data is described where each JSON structure lists a "type" in the form .. Should we be using self-describing discovery schemas like JSON-Schema and/or JSON-LD?

Describe the change you would like to propose
In the current spec, we use JSON Schema because it allows the ability to say what attributes are needed in what combinations. JSON-LD handles referential information but does not describe more complete sets of attributes (e.g. attribute a requires b or c).

We could adopt a form:
{
"id": "CanaryProfileService",
"$schema": "https://config.example.com/schema/canaryapi.schema",
"subscription": "s1234567890",
"resourceGroup": "xyz",
"api-id": "8763f1c4-0000-0000-0000-158e9ef97d6a",
"location": "us-east-1",
"stage-name": "",
"resoource": "/Profile/*"
}

Where $schema points to the JSON-Schema format of the current Asset that describes the current set of claims of the object.

What do you feel is the ideal solution?
This likely depends on how the open source API Gateway evolves.

What would be a minimal or good enough solution if any?
TB discussed

Additional context

@independentid independentid changed the title Use a $ref instead of type in Object Schema Use a $schema instead of type in Object Schema Dec 27, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant