1
- ### JSON Hyper-Schema Draft-07 Release Notes
1
+ ---
2
+ title : JSON Hyper-Schema Draft-07 Release Notes
3
+ section : docs
4
+ ---
2
5
3
6
JSON Hyper-Schema [ draft-07] ( ../../draft-07/json-schema-hypermedia.html ) completes the
4
7
reworking of Hyper-Schema that was begun in draft-06.
@@ -9,55 +12,56 @@ so keywords used for other purposes (`readOnly` and `media`) have been
9
12
10
13
The [ new draft] ( ../../draft-07/json-schema-hypermedia.html ) has been completely rewritten
11
14
for clarity and accessibility, so it is best to simply approach it as a new
12
- proposal.
15
+ proposal. We hope to add tutorial material at some point, but that is
16
+ outside of the scope of release notes.
13
17
14
18
However, if you wish to migrate from an earlier draft, this page is a guide
15
- to the key changes. The additions, which are much more numerous,
19
+ to the key _ changes _ . The additions, which are much more numerous,
16
20
should be learned directly from the new specification until we can provide
17
21
tutorials.
18
22
19
23
Note that draft-handrews-json-schema-hyperschema-00 has been replaced
20
24
by draft-handrews-json-schema-hyperschema-01 in order to fix confusing
21
- bugs. The newer -01 draft is ** still considered to be draft-07** .
25
+ bugs. The newer -01 draft is ** still considered to be draft-07** .
22
26
It now references the draft-07 meta-schema with the correct URI, among
23
- other typo fixes. There are no funcitonal changes between -00 and -01.
27
+ other typo fixes. There are no funcitonal changes between -00 and -01.
24
28
25
- - [ Migrating from draft-06] ( #migrating-from-draft-06 )
26
- - [ Migrating from draft-05] ( #migrating-from-draft-05 )
27
- - [ Migrating from draft-04] ( #migrating-from-draft-04 )
28
- - [ GET] ( #get )
29
- - [ PUT] ( #put )
30
- - [ DELETE] ( #delete )
31
- - [ POST] ( #post )
32
- - [ PATCH] ( #patch )
29
+ * [ Migrating from draft-06] ( #migrating-from-draft-06 )
30
+ * [ Migrating from draft-05] ( #migrating-from-draft-05 )
31
+ * [ Migrating from draft-04] ( #migrating-from-draft-04 )
32
+ * [ GET] ( #get )
33
+ * [ PUT] ( #put )
34
+ * [ DELETE] ( #delete )
35
+ * [ POST] ( #post )
36
+ * [ PATCH] ( #patch )
33
37
34
- #### Migrating from draft-06
38
+ ### Migrating from draft-06
35
39
36
40
No draft-06 features were changed, although two keywords were renamed
37
41
for clarity and consistency:
38
42
39
- - ` mediaType ` -> ` targetMediaType `
40
- - ` submissionEncType ` -> ` submissionMediaType `
43
+ * ` mediaType ` -> ` targetMediaType `
44
+ * ` submissionEncType ` -> ` submissionMediaType `
41
45
42
46
Additionally, ` hrefSchema ` was somewhat confusing, so a great deal
43
47
more effort has gone into explaining how it works, and how it fits
44
48
into the overall link resolution process.
45
49
46
- #### Migrating from draft-05
50
+ ### Migrating from draft-05
47
51
48
52
See the [ draft-06 release notes] ( ../../draft-06/json-hyper-schema-release-notes )
49
53
for information related to draft-05.
50
54
51
- #### Migrating from draft-04
55
+ ### Migrating from draft-04
52
56
53
57
In the ideal draft-07 world, links and
54
58
[ operations] ( https://json-schema.org/draft-07/json-schema-hypermedia.html#rfc.section.3.1 )
55
- are not the same concept. Using terminology borrowed from
59
+ are not the same concept. Using terminology borrowed from
56
60
[ OpenAPI's Operation Object] ( https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#operationObject ) , HTTP methods are operations, and each
57
61
link (as described by a single LDO) can support multiple operations.
58
62
59
63
Therefore, unlike draft-04, draft-07 hyper-schemas
60
- [ do not have separate links for each operation] ( ../../draft-07/json-schema-hypermedia.html#rfc.section.8.1 ) . This makes the migration guidelines below approximate at best.
64
+ [ do not have separate links for each operation] ( ../../draft-07/json-schema-hypermedia.html#rfc.section.8.1 ) . This makes the migration guidelines below approximate at best.
61
65
62
66
For a more detailed explanation of how draft-04's ` method ` and ` targetSchema `
63
67
were typically used to create single-operation links, and how that poses
@@ -75,53 +79,53 @@ means that some uses of draft-04 do not have direct analogues in draft-07.
75
79
76
80
Any keyword not mentioned in a list below is unchanged for that link operation.
77
81
78
- ##### GET
82
+ #### GET
79
83
80
- - ` "method": "GET" ` -> ` "targetHints": {"allow": ["GET"]} `
81
- - ` mediaType ` -> ` targetMediaType `
82
- - ` schema ` -> ` hrefSchema ` with parameters added to ` href `
83
- - ` encType ` -> drop if ` application/x-www-form-urlencoded ` , contact the mailing list otherwise
84
+ * ` "method": "GET" ` -> ` "targetHints": {"allow": ["GET"]} `
85
+ * ` mediaType ` -> ` targetMediaType `
86
+ * ` schema ` -> ` hrefSchema ` with parameters added to ` href `
87
+ * ` encType ` -> drop if ` application/x-www-form-urlencoded ` , contact the mailing list otherwise
84
88
85
- ##### PUT
89
+ #### PUT
86
90
87
91
If you have a PUT link where ` schema ` /` encType ` differ from
88
92
` targetSchema ` /` mediaType ` , where ` targetSchema ` /` mediaType `
89
93
describe a non-representation response, then those fields do
90
94
not have a direct replacement.
91
95
92
- - ` "method": "PUT" ` -> ` "targetHints": {"allow": ["PUT"]} `
93
- - ` schema ` -> ` targetSchema `
94
- - ` encType ` -> ` targetMediaType `
96
+ * ` "method": "PUT" ` -> ` "targetHints": {"allow": ["PUT"]} `
97
+ * ` schema ` -> ` targetSchema `
98
+ * ` encType ` -> ` targetMediaType `
95
99
96
- ##### DELETE
100
+ #### DELETE
97
101
98
102
DELETE does not take a request payload, so ` schema ` and ` encType `
99
- should be unused. If ` targetSchema ` and ` mediaType ` were being
103
+ should be unused. If ` targetSchema ` and ` mediaType ` were being
100
104
used for a response other than the just-deleted resource's representation,
101
105
then they do not have a direct replacement.
102
106
103
- - ` "method": "DELETE" ` -> ` "targetHints": {"allow": ["DELETE"]} `
104
- - ` mediaType ` -> ` targetMediaType ` (if describing the representation)
107
+ * ` "method": "DELETE" ` -> ` "targetHints": {"allow": ["DELETE"]} `
108
+ * ` mediaType ` -> ` targetMediaType ` (if describing the representation)
105
109
106
- ##### POST
110
+ #### POST
107
111
108
112
In most cases, the response of a POST is ** not** a representation of the
109
113
target resource, but rather some sort of result or status of whatever
110
- the POST attempted to do. Therefore ` targetSchema ` and ` mediaType `
111
- should almost certainly be dropped. Other than that:
114
+ the POST attempted to do. Therefore ` targetSchema ` and ` mediaType `
115
+ should almost certainly be dropped. Other than that:
112
116
113
- - ` "method": "POST" ` -> ` "targetHints": {"allow": ["POST"]} `
114
- - ` schema ` -> ` submissionSchema `
115
- - ` encType ` -> ` submissionMediaType `
117
+ * ` "method": "POST" ` -> ` "targetHints": {"allow": ["POST"]} `
118
+ * ` schema ` -> ` submissionSchema `
119
+ * ` encType ` -> ` submissionMediaType `
116
120
117
- ##### PATCH
121
+ #### PATCH
118
122
119
123
It was never entirely clear how to model a proper PATCH (that uses
120
124
a patch media type rather than ` application/json ` in the request) in Hyper-Schema.
121
125
One option was to treat it identically to PUT except with the patch media type
122
- in ` encType ` . Assuming that approach (and the same ` taregetSchema ` /` mediaType `
126
+ in ` encType ` . Assuming that approach (and the same ` taregetSchema ` /` mediaType `
123
127
caveats as for PUT):
124
128
125
- - ` "method": "PATCH" ` -> ` "targetHints": {"allow": ["PATCH"]} `
126
- - ` schema ` -> ` targetSchema `
127
- - ` "encType": "..." ` -> ` "targetHints": {"accept-patch": "..."} `
129
+ * ` "method": "PATCH" ` -> ` "targetHints": {"allow": ["PATCH"]} `
130
+ * ` schema ` -> ` targetSchema `
131
+ * ` "encType": "..." ` -> ` "targetHints": {"accept-patch": "..."} `
0 commit comments