|
185 | 185 | binary data treated as a PNG image.
|
186 | 186 | It also defines link relations for the instance, with URIs incorporating values
|
187 | 187 | from the instance.
|
188 |
| - <cref> |
189 |
| - "id" probably should not normally be a required keyword, since new instances |
190 |
| - will have an unknown "id" property until is it assigned by the server. |
191 |
| - However, this property is used in a link, and without it, multiple different |
192 |
| - instances would be given the same rel=self URI! |
193 |
| - </cref> |
194 | 188 | </postamble>
|
195 | 189 | </figure>
|
196 | 190 |
|
|
662 | 656 |
|
663 | 657 | <section title="Missing values" anchor="missingValues">
|
664 | 658 | <t>
|
665 |
| - Sometimes, the appropriate values will not be available. |
666 |
| - For example, the template might specify the use of object properties, |
667 |
| - but no such data was provided (or "hrefSchema" is not present), and the |
668 |
| - instance is an array or a string. |
| 659 | + Sometimes, the appropriate values will not be available. In many |
| 660 | + cases, the URI Template behavior of simply removing varibles that |
| 661 | + do not have a value will be appropriate. An example of this is |
| 662 | + optional query parameters, the presence or absence of which does |
| 663 | + not change the nature of the link relation type. |
669 | 664 | </t>
|
670 | 665 |
|
671 | 666 | <t>
|
672 |
| - If any of the values required for the template are neither present in |
673 |
| - the user agent data (if relevant) nor the JSON instance, then substitute |
674 |
| - values MAY be provided from another source (such as default values). |
675 |
| - Otherwise, the link definition SHOULD be considered not to apply to the |
676 |
| - instance. |
| 667 | + However, some variables, such as an identifier used in a path component, |
| 668 | + cannot meaningfully be omitted. The resulting URI would be meaningless, |
| 669 | + or would require a different link relation type. While "hrefSchema" can |
| 670 | + express a requirement for those variables that can be supplied via input, |
| 671 | + some variables must be resolved from instance data. When that instance |
| 672 | + data is not required by the context schema, the |
| 673 | + <xref target="hrefRequired">"hrefRequired</xref> keyword may be used to |
| 674 | + indicate that when the instance data is not available, the link does |
| 675 | + not apply. |
677 | 676 | </t>
|
678 | 677 | </section>
|
679 | 678 | </section>
|
|
727 | 726 | "hrefPointers": {
|
728 | 727 | "rootId": "/id",
|
729 | 728 | "parentId": "2/id"
|
730 |
| - } |
| 729 | + }, |
| 730 | + "hrefRequired": ["parentId"] |
731 | 731 | }
|
732 | 732 | ]
|
733 | 733 | }]]>
|
|
779 | 779 | </t>
|
780 | 780 | <t>
|
781 | 781 | For the root node, the relative pointer for the parent doesn't point
|
782 |
| - to anything. As noted under |
783 |
| - <xref target="missingValues">missing values</xref>, such a link should |
784 |
| - simply be ignored. |
785 |
| - <cref> |
786 |
| - GitHub issue #49 tracks the question of distinguishing this situation |
787 |
| - of a missing required variable (common in path components) from |
788 |
| - missing optional variables (common in query string parameters). |
789 |
| - </cref> |
| 782 | + to anything, so <xref target="hrefRequired">"hrefRequired"</xref> |
| 783 | + prevents the link from being used with that node. |
790 | 784 | </t>
|
791 | 785 | </section>
|
792 | 786 |
|
|
881 | 875 | </t>
|
882 | 876 | </section>
|
883 | 877 |
|
| 878 | + <section title="hrefRequired" anchor="hrefRequired"> |
| 879 | + <t> |
| 880 | + The value of this keyword MUST be an array, and the elements MUST be unique. |
| 881 | + Each element SHOULD match a variable in the link's URI Template, without |
| 882 | + percent-encoding. After completing the entire URI Template resolution |
| 883 | + process, if any variable that is present in this array does not have |
| 884 | + a value, the link MUST NOT be used. |
| 885 | + </t> |
| 886 | + <figure> |
| 887 | + <preamble> |
| 888 | + Here is a simplified version of the "up" link from the |
| 889 | + <xref target="hrefPointers">"hrefPointers</xref> tree example, |
| 890 | + modified to only use the parent identifier for its "href" template. |
| 891 | + While each individual node is required to have an "id" field, the |
| 892 | + "up" link uses the parent node's field, and the root node, by definition, |
| 893 | + does not have a parent node. Putting "parentId" in "hrefRequired" ensures |
| 894 | + that the "up" link is correctly unusable with the root node. |
| 895 | + </preamble> |
| 896 | + <artwork> |
| 897 | +<![CDATA[{ |
| 898 | + "rel": "up", |
| 899 | + "href": "/nodes/{parentId}", |
| 900 | + "hrefPointers": { |
| 901 | + "parentId": "2/id" |
| 902 | + }, |
| 903 | + "hrefRequired": ["parentId"] |
| 904 | +}]]> |
| 905 | + </artwork> |
| 906 | + </figure> |
| 907 | + </section> |
| 908 | + |
884 | 909 | <section title="rel" anchor="rel">
|
885 | 910 | <t>
|
886 | 911 | The value of the "rel" property indicates the name of the relation to the target
|
|
0 commit comments