Closed renzenicolai closed 1 month ago
I remember discussing this as part of https://github.com/SpaceApi/schema/pull/75, but apparently not on the PR itself but somewhere else. As far as I remember @gidsi had some reasons not to use the SpaceAPI endpoint, but I can't recall them.
Edit: Found some stuff in the meeting notes:
The discussions are linked in the PR :)
I can write something about the "why" later
@SpaceApi/core I think we should have another look at this PR:
/.well-known/spaceapi.json
. However, this is not the case currently, and even if we decided to go this way, it would take ages for all endpoints to migrate to the new path. Only linking to the base URL would make it impossible to link to spaces that have not migrated their endpoint to the new location.<meta name="spaceapi">
HTML tag proposed in #144, clients would suddenly need to parse HTML in addition to JSON.If we decide to merge this PR, I'd even go so far as to make the endpoint
field mandatory and remove the url
field (at least for now), as it would not serve any purpose at the moment, and would probably create confusion.
I agree with @s3lph. I think we should stick to endpoint URLs for now. They are easy to understand, allow for easy redirecting, and don't require any additional parsing.
If we decide to support some .well-known/...
-scheme, we can always add that later on.
Decision in today's SpaceAPI core meeting:
url
to website
website
and endpoint
, with anyOf
requirement (i.e. make none of them required)Hm unless I'm mistaken the "any of" requirement can't be modeled with JSONSchema. We could use minProperties: 1
, but that would also pass validation if ONLY non-standard ext_
fields are provided. We could work around that with additionalProperties: false
but that would prevent the use of ext_
fields entirely in this specific location.
Hm unless I'm mistaken the "any of" requirement can't be modeled with JSONSchema.
Why not? Reading https://json-schema.org/understanding-json-schema/reference/combining#anyOf it looks like it should be possible.
Huh... why is anyOf
in the JSONSchema core spec, but required
is in the validation spec? No wonder I didn't find it in the latter one.
So I guess we'd need to use something like this?
"linked_spaces": {
"type": "array",
"items": {
"anyOf": [
{
"type": "object",
"properties": {
"endpoint": {
"type": "string"
}
},
"required": ["endpoint"]
},
{
"type": "object",
"properties": {
"website": {
"type": "string"
}
},
"required": ["website"]
}
]
}
}
To my understanding you can extract all commen things out of the anyOf and just keep the required in it.
Rename url to website
Should we deprecate url
first before removing it?
Rename url to website
Should we deprecate
url
first before removing it?
Why? The old field was never released, so we can change it freely 🙂
Why? The old field was never released, so we can change it freely 🙂
Ah true :laughing:
By adding a field to specify the SpaceAPI endpoints of other spaces self discovery of the spaces in the SpaceAPI network becomes possible. This change would eventually allow for a SpaceAPI that is functional without the central directory.
If the endpoint field is filled out then the URL field of the linked space should be left absent as the url can instead be read from the spaces own SpaceAPI endpoint. Because of this I've made the URL endpoint optional.