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

Support URI input with "hrefSchema" #228

Merged
merged 2 commits into from
Jan 23, 2017
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 4 additions & 0 deletions hyper-schema.json
Original file line number Diff line number Diff line change
Expand Up @@ -20,6 +20,10 @@
"description": "a URI template, as defined by RFC 6570, with the addition of the $, ( and ) characters for pre-processing",
"type": "string"
},
"hrefSchema": {
"description": "a schema for validating user input to the URI template, where the input is in the form of a JSON object with property names matching variable names in \"href\"",
"allOf": [ {"$ref": "#"} ]
},
"rel": {
"description": "relation to the target resource of the link",
"type": "string"
Expand Down
155 changes: 143 additions & 12 deletions jsonschema-hyperschema.xml
Original file line number Diff line number Diff line change
Expand Up @@ -366,9 +366,33 @@
The URI of the normative link description schema is: <eref target="http://json-schema.org/draft-04/links">http://json-schema.org/draft-04/links</eref> (draft-04 version).
</t>

<t>
"Form"-like functionality can be defined by use of the "method" and "schema" keywords, which supplies a schema describing the data to supply to the server.
</t>
<section title="Links and data">
<t>
"Form"-like functionality can be defined by use of the <xref target="method">"method"</xref> and <xref target="schema">"schema"</xref> keywords, which supplies a schema describing the data to supply to the server.
Functionality equivalent to dynamic URI generation is available through the <xref target="href">"href"</xref> template and <xref target="hrefSchema">"hrefSchema"</xref>.
</t>
<t>
The simplest kind of link has an "href" with no template variables, and no "schema". This does not
allow for any variance in the link URI, nor does it allow for a request document.
</t>
<t>
An "href" with at least one template variable, but no "hrefSchema" or "schema", allows resolving
the template variable from the instance, but does not allow resolving it
from external data, nor does it allow a request document.
</t>
<t>
An "href" with at least one template variable and with an "hrefSchema" allows using external
data to resolve the template, and falls back to resolving any remaining variables from the instance.
</t>
<t>
A link with a "schema" allows submitting external data either as a request body (if "method" is "post"),
or as a URI query string (if "method" is "get"). Such a query string replaces any query string
present after the "href" template is resolved.
</t>
<t>
See the individual keyword descriptions below for details related to each of these cases.
</t>
</section>

<!-- Possibly include a short section on motivations, including triples, resources, and progressive disclosure -->

Expand Down Expand Up @@ -473,20 +497,32 @@

<section title="Values for substitution">
<t>
After pre-processing, the URI Template is filled out using data from the instance.
After pre-processing, the URI Template is filled out using data from some combination of an externa source and the instance.
Where either instance data or external data may be used, this section will refer simply to "data" or to a "value".
When the source is important, it is specified explicitly.

To allow the use of any object property (including the empty string), array index, or the instance value itself, the following rules are defined:
</t>

<t>
For a given variable name in the URI Template, the value to use is determined as follows:
<list>
<t>If the variable name is "%73elf", then the instance value itself MUST be used.</t>
<t>If the variable name is "%65mpty", then the instances's empty-string ("") property MUST be used (if it exists).</t>
<t>If the instance is an array, and the variable name is a representation of a non-negative integer, then the value at the corresponding array index MUST be used (if it exists).</t>
<t>If the variable name is "%73elf", then the value itself MUST be used.</t>
<t>If the variable name is "%65mpty", then the empty-string ("") property MUST be used (if it exists).</t>
<t>If the data is an array, and the variable name is a representation of a non-negative integer, then the value at the corresponding array index MUST be used (if it exists).</t>
<t>Otherwise, the variable name should be percent-decoded, and the corresponding object property MUST be used (if it exists).</t>
</list>
</t>

<t>
If <xref target="hrefSchema">"hrefSchema"</xref> is present and
external input is provided, the input MUST be a valid instance according
to the value of "hrefSchema".
Template variables, after the process listed above, MUST first
be resolved from the external data instance. Any variables left
unresolved MUST be resolved from the resource instance data.
</t>

<section title="Converting to strings">
<t>
When any value referenced by the URI template is null, a boolean or a number, then it should first be converted into a string as follows:
Expand All @@ -506,18 +542,109 @@
<section title="Missing values">
<t>
Sometimes, the appropriate values will not be available.
For example, the template might specify the use of object properties, but the instance is an array or a string.
For example, the template might specify the use of object properties, but no such input was provide (or "hrefSchema" is not present), and the instance is an array or a string.
</t>

<t>
If any of the values required for the template are not present in the JSON instance, then substitute values MAY be provided from another source (such as default values).
If any of the values required for the template are present in neither the user input (if relevant) or the JSON instance, then substitute values MAY be provided from another source (such as default values).
Otherwise, the link definition SHOULD be considered not to apply to the instance.
</t>
</section>
</section>

</section>

<section title="hrefSchema" anchor="hrefSchema">
<t>
The value of the "hrefSchema" link description property MUST be
a valid JSON Schema. This schema is used to validate user input
or other external data for filling out the URI Template in
<xref target="href">"href"</xref>, as described in that section.
</t>
<t>
Omitting "hrefSchema" or setting the entire schema to "false" prevents
any external data from being accepted.
</t>
<t>
Implementations MUST NOT attempt to validate values resolved from
resource instance data with "hrefSchema". This allows for different
validation rules for user input, such as supporting spelled-out
months for date-time input but using the standard date-time
format for storage.
</t>
<figure>
<preamble>
For example, this defines a schema for each of the query string
parameters in the URI template:
</preamble>
<artwork>
<![CDATA[{
"href": "/foos{?condition,count,query}",
"hrefSchema": {
"properties": {
"condition": {
"type": "boolean",
"default": true
},
"count": {
"type": "integer",
"minimum": 0,
"default": 0
},
"query": {
"type": "string"
}
}
}
}]]>
</artwork>
</figure>
<figure>
<preamble>
In this example, the schema for "extra" is given as a reference
to keep the external data validation constraints identical to the
instance validation constraints for the corresponding property,
while "id" is given a false schema to prevent external data for
that variable.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I understand the first part of this explanation, but not the second part.

..."id" is given a false schema to prevent user input for that variable

For easy reference...

...
"href": "/things/{id}{?extra}",
        "hrefSchema": {
            "properties": {
                "id": false,
                "extra": {"$ref": "#/definitions/extra"}
            }
        }
...

Maybe this is my lack of understand of HyperSchema, but how does having it in hrefSchema allow it as input? In terms of input in the URL? If so, is it implying that an invalid URI is things/123 while a valid URI is things/abc? This is really unclear and confusing to me.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, @Relequestual and I talked on IRC and identified some unclear wording that led to his confusion. I am going to rework that and then update this PR.

</preamble>
<artwork>
<![CDATA[{
"definitions": {
"extra": {
"type": "string",
"maxLength": 32
}
},
"type": "object",
"properties": {
"id": {
"type": "integer",
"minimum": 1,
"readOnly": true
},
"extra": {"$ref": "#/definitions/extra"}
},
"links": [{
"rel": "self",
"href": "/things/{id}{?extra}",
"hrefSchema": {
"properties": {
"id": false,
"extra": {"$ref": "#/definitions/extra"}
}
}
}]
}]]>
</artwork>
</figure>
<t>
<cref>
The above example simulates the behavior found in earlier drafts using only "hrefSchema",
which would allow the concurrent use of "schema" on a "post" link.
</cref>
</t>
</section>

<section title="rel">
<t>
The value of the "rel" property indicates the name of the relation to the target resource. The value MUST be a registered link relation from the <xref target="RFC5988">IANA Link Relation Type Registry established in RFC 5988</xref>, or a normalized URI following the <xref target="RFC3986">URI production of RFC 3986</xref>.
Expand Down Expand Up @@ -784,7 +911,7 @@ GET /foo/
The following properties also apply to Link Description Objects, and provide functionality analogous to <xref target="W3C.CR-html5-20140731">HTML forms</xref>, by providing a means for making a request with client- or user-selected information.
</t>

<section title="method">
<section title="method" anchor="method">
<t>
This property specifies that the client can construct a templated query or non-idempotent request to a resource.
</t>
Expand Down Expand Up @@ -839,13 +966,16 @@ GET /foo/
</t>
</section>

<section title="schema">
<section title="schema" anchor="schema">
<t>
This property contains a schema which defines the acceptable structure of the document being encoded according to the "encType" property.
</t>

<t>
Note that this does not provide data for any URI templates.
Note that this does not provide data for any URI templates. That is handed by <xref target="hrefSchema">"hrefSchema"</xref>. If the method is "get" and the resolved URI Template has a query string, the query string produced by input validated agaisnt "schema" replaces the existing query string.
</t>

<t>
This is a separate concept from the "targetSchema" property, which is describing the target information resource (including for replacing the contents of the resource in a PUT request), unlike "schema" which describes the user-submitted request data to be evaluated by the resource.
</t>
</section>
Expand Down Expand Up @@ -916,6 +1046,7 @@ GET /foo/
<t hangText="draft-wright-json-schema-hyperschema-01">
<list style="symbols">
<t>Fixed examples</t>
<t>Added "hrefSchema" for user input to "href" URI Templates</t>
</list>
</t>
<t hangText="draft-wright-json-schema-hyperschema-00">
Expand Down
4 changes: 4 additions & 0 deletions links.json
Original file line number Diff line number Diff line change
Expand Up @@ -9,6 +9,10 @@
"description": "a URI template, as defined by RFC 6570, with the addition of the $, ( and ) characters for pre-processing",
"type": "string"
},
"hrefSchema": {
"description": "a schema for validating user input to the URI template, where the input is in the form of a JSON object with property names matching variable names in \"href\"",
"allOf": [ {"$ref": "#"} ]
},
"rel": {
"description": "relation to the target resource of the link",
"type": "string"
Expand Down