611
611
serialization formats. User agents MAY use this information to inform
612
612
the interface they present to the user before the link is followed,
613
613
but MUST NOT use this information in the interpretation of the resulting
614
- data. Instead, a client MUST use the media type given by the response for
615
- run-time interpretation. See the section on
614
+ data. Instead, a user agent MUST use the media type given by the response
615
+ for run-time interpretation. See the section on
616
616
<xref target =" security" >"Security Concerns"</xref > for a detailed
617
617
examination of mis-use of "targetMediaType".
618
618
</t >
681
681
</t >
682
682
<t >
683
683
Implementations MUST NOT assume that all discoverable information is
684
- accounted for in this object. Clients MUST properly handle run-time
685
- responses that contradict this property's values.
684
+ accounted for in this object. Client applications MUST properly handle
685
+ run-time responses that contradict this property's values.
686
686
</t >
687
687
<t >
688
- Clients MUST NOT assume that an implementation will automatically take any
689
- action based on the value of this property.
688
+ Client applications MUST NOT assume that an implementation will
689
+ automatically take any action based on the value of this property.
690
690
</t >
691
691
<t >
692
692
See <xref target =" HTTP" >"JSON Hyper-Schema and HTTP"</xref > for
696
696
</section >
697
697
<section title =" Link Input" anchor =" input" >
698
698
<t >
699
- There are four ways to use client-supplied data with a link, and each
699
+ There are four ways to use client input with a link, and each
700
700
is addressed by a separate link description object keyword. When performing
701
- operations, clients SHOULD ignore schemas that are not relevant to their
701
+ operations, user agents SHOULD ignore schemas that are not relevant to their
702
702
semantics.
703
703
</t >
704
704
<section title =" hrefSchema" anchor =" hrefSchema" >
759
759
</t >
760
760
<t >
761
761
The purpose of this keyword is to advertise target resource interaction
762
- features, and indicate to clients what headers and header values are
763
- likely to be useful. Clients MAY use the schema to validate relevant
762
+ features, and indicate to user agents and client applications what headers
763
+ and header values are likely to be useful.
764
+ User agents and client applications MAY use the schema to validate relevant
764
765
headers, but MUST NOT assume that missing headers or values are forbidden
765
766
from use. While schema authors MAY set "additionalProperties" to
766
- false, this is NOT RECOMMENDED and MUST NOT prevent clients or user agents
767
- from supplying additional headers when requests are made.
767
+ false, this is NOT RECOMMENDED and MUST NOT prevent client applications
768
+ or user agents from supplying additional headers when requests are made.
768
769
</t >
769
770
<t >
770
771
The exact mapping of the JSON data model into the headers is
777
778
</t >
778
779
<t >
779
780
"headerSchema" is applicable to any request method or command that the
780
- protocol supports. When generating a request, clients SHOULD ignore
781
- schemas for headers that are not relevant to that request.
781
+ protocol supports. When generating a request, user agents and client
782
+ applications SHOULD ignore schemas for headers that are not relevant
783
+ to that request.
782
784
</t >
783
785
</section >
784
786
785
787
<section title =" Manipulating the Target Resource Representation" >
786
788
<t >
787
789
In JSON Hyper-Schema, <xref target =" targetSchema" >"targetSchema"</xref >
788
790
supplies a non-authoritative description of the target resource's
789
- representation. A client can use "targetSchema" to structure input for
790
- replacing or modifying the representation, or as the base representation
791
- for building a patch document based on a patch media type.
791
+ representation. A client application can use "targetSchema" to structure
792
+ input for replacing or modifying the representation, or as the base
793
+ representation for building a patch document based on a patch media type.
792
794
</t >
793
795
<t >
794
- Alternatively, if "targetSchema" is absent or if the client prefers to
795
- only use authoritative information, it can interact with the target
796
- resource to confirm or discover its representation structure.
796
+ Alternatively, if "targetSchema" is absent or if the client application
797
+ prefers to only use authoritative information, it can interact with the
798
+ target resource to confirm or discover its representation structure.
797
799
</t >
798
800
<t >
799
801
"targetSchema" is not intended to describe link operation responses,
817
819
<section title =" submissionMediaType" anchor =" submissionMediaType" >
818
820
<t >
819
821
If present, this property indicates the media type format the
820
- client should use for the request payload described by
822
+ client application and user agent should use for the request
823
+ payload described by
821
824
<xref target =" submissionSchema" >"submissionSchema"</xref >.
822
825
</t >
823
826
<t >
910
913
</t >
911
914
<t hangText =" attachmentPointer" >
912
915
The JSON Pointer for the location within the instance to which the
913
- link is attached. By default, "contextUri" and "attachementUri " are
916
+ link is attached. By default, "contextUri" and "attachmentUri " are
914
917
the same, but "contextUri" can be changed by LDO keywords, while
915
918
"attachmentUri" cannot.
916
919
</t >
@@ -1345,11 +1348,11 @@ for varname in templateData:
1345
1348
<t >
1346
1349
Since the semantics of many HTTP methods are defined in terms of the target
1347
1350
resource, "targetSchema" is used for requests and/or responses for several
1348
- HTTP methods.
1349
- In particular, "targetSchema" suggests what a client can expect for the
1350
- response to an HTTP GET or any response for which the "Content-Location"
1351
- header is equal to the request URI, and what a client should send if it
1352
- replaces the resource in an HTTP PUT request.
1351
+ HTTP methods. In particular, "targetSchema" suggests what a client
1352
+ application can expect for the response to an HTTP GET or any response
1353
+ for which the "Content-Location" header is equal to the request URI,
1354
+ and what a client application should send if it replaces the resource
1355
+ in an HTTP PUT request.
1353
1356
These correlations are defined by <xref target =" RFC7231" >RFC 7231,
1354
1357
section 4.3.1 - "GET", section 4.3.4 "PUT", and section 3.1.4.2,
1355
1358
"Content-Location"</xref >.
@@ -1483,8 +1486,8 @@ for varname in templateData:
1483
1486
include the URI(s) of the schema(s) to which the negotiated representation
1484
1487
is expected to conform. One possible use for schema parameters in
1485
1488
content negotiation is if the resource has conformed to several different
1486
- schema versions over time. The client can indicate what version(s) it
1487
- understands in the "Accept" header in this way.
1489
+ schema versions over time. The client application can indicate what version(s)
1490
+ it understands in the "Accept" header in this way.
1488
1491
</t >
1489
1492
</section >
1490
1493
</section >
@@ -1772,10 +1775,10 @@ Link: <https://schema.example.com/entry> rel=describedBy
1772
1775
<t hangText =" title:" >
1773
1776
The instance field matching this variable is required, and it is also
1774
1777
allowed in the input data. So its instance value is used to
1775
- pre-populate the input data set before accepting the client's input.
1776
- The client can opt to leave the instance value in place. Since
1777
- this field is required in "hrefSchema", the client cannot delete it
1778
- (although it could set it to an empty string).
1778
+ pre-populate the input data set before accepting client input. The
1779
+ client application can opt to leave the instance value in place. Since
1780
+ this field is required in "hrefSchema", the client application cannot
1781
+ delete it (although it could set it to an empty string).
1779
1782
</t >
1780
1783
<t hangText =" cc:" >
1781
1784
The "false" schema set for this in the main schema prevents this field
@@ -1799,7 +1802,7 @@ Link: <https://schema.example.com/entry> rel=describedBy
1799
1802
</figure >
1800
1803
<t >
1801
1804
We can partially resolve the link as follows, before asking the client
1802
- for input.
1805
+ application for input.
1803
1806
</t >
1804
1807
<figure >
1805
1808
<artwork >
@@ -2407,8 +2410,9 @@ Link: <https://api.example.com/trees/1/nodes/456> rev=up
2407
2410
</cref >
2408
2411
</t >
2409
2412
<t >
2410
- Clients MUST NOT use the value of "targetSchema" to aid in the interpretation
2411
- of the data received in response to following the link, as this leaves
2413
+ User agents or client applications MUST NOT use the value of "targetSchema"
2414
+ to aid in the interpretation of the data received in response to following
2415
+ the link, as this leaves
2412
2416
"safe" data open to re-interpretation.
2413
2417
</t >
2414
2418
<t >
0 commit comments