rjsf-team
$ref doesn't support url
Here is a valid schema:
{
"title": "A registration form",
"description": "A simple form example.",
"type": "object",
"required": [
"address"
],
"properties": {
"address": {
"$ref": "https://api.myjson.com/bins/3bkzl.json#/definitions/address"
}
}
}
It throws exception when dereference $ref.
Not sure if we should implement this... could you look through the JSON Schema spec (https://json-schema.org/) and see what it might have to say about $ref's with a HTTPS url?
The specification is very explicit in saying on section 8.3 that:
The "$ref" keyword is used to reference a schema, and provides the ability to validate recursive structures through self-reference.
An object schema with a "$ref" property MUST be interpreted as a "$ref" reference. The value of the "$ref" property MUST be a URI Reference. Resolved against the current URI base, it identifies the URI of a schema to use. All other properties in a "$ref" object MUST be ignored.
The URI is not a network locator, only an identifier. A schema need not be downloadable from the address if it is a network-addressable URL, and implementations SHOULD NOT assume they should perform a network operation when they encounter a network-addressable URI.
On the latest draft, this section is here.
Nevertheless, I would also like to see this feature supported being it out-of-the-box or by allowing its users to provide their own URL resolver implementation.
I like the idea of users being able to choose between several given $ref resolver implementations (JSON pointer, URL, or a combination of multiple ones), and also provide their own custom $ref resolver implementation if they want.
In JSON schema draft 2020-12 (which is the latest as of writing this) this is specified:
The value of the "$ref" keyword MUST be a string which is a URI-Reference. Resolved against the current URI base, it produces the URI of the schema to apply.
For the definition of "URI-Reference" the document links to RFC3986 in one place.
This means to me that any absolute URI would be valid here, even schemes other than http:// and https://. But so far I haven't found any specification on whether processors must support any certain protocol.
Personally I would like to add my +1 for implementing HTTP(S) resolving, as we are working towards modularising schema and referencing it directly via absolute HTTPS URLs. This happening in a browser context will probably mean some requirements for servers though (sending CORS headers, handling OPTIONS requests).
