14 |
15 |
16 |
17 |
18 |
19 |
20 |
21 |
--------------------------------------------------------------------------------
/includes/uber-query-string.txt:
--------------------------------------------------------------------------------
1 |
2 |
6 |
7 | Assume the values supplied are:
8 | givenName = Mike
9 | familyName = Amundsen
10 | email = mike@example.org
11 |
12 | *** HTTP Request ***
13 | GET /search/?g=Mike&f=Amundsen&e=mike%40example.org HTTP/1.1
14 | Host: example.org
15 | Accept-Type: application/vnd.amundsen-uber+xml
16 |
17 |
--------------------------------------------------------------------------------
/uber-hypermedia.html:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 |
6 |
7 | If you are not redirected automatically, please visit the new home of this document at: http://rawgit.com/uber-hypermedia/specification/master/uber-hypermedia.html
8 |
9 |
10 |
--------------------------------------------------------------------------------
/uber-apps/tasks/README.md:
--------------------------------------------------------------------------------
1 | # Uber Server - Tasks Hypermedia
2 |
3 | This is a simple server implementation as a POC (proof of concept) to the
4 | Uber media type design.
5 |
6 | Everything in this sample should be treated as ["Informative" and
7 | not "Normative"](https://www.ietf.org/iesg/statement/normative-informative.html).
8 |
9 | Since it's a demo app and not part of any spec, you should assume it will
10 | change quite a bit.
11 |
12 | Feel free to post to the Issues section if you have comments/suggestions on how to improve this demo app.
13 |
14 | If you find bugs, just send me a PR and I'll roll it in.
15 |
16 | _Cheers_ @mamund
17 |
--------------------------------------------------------------------------------
/includes/search-sample.xml:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 |
6 | Clean House
7 | 2014-05-01
8 |
9 |
10 | Paint the fence
11 | 2014-06-01
12 |
13 |
14 |
15 |
--------------------------------------------------------------------------------
/includes/uber-request-body.txt:
--------------------------------------------------------------------------------
1 |
2 |
7 |
8 | Assume the values supplied are:
9 | givenName = Mike
10 | familyName = Amundsen
11 | email = mike@example.org
12 | avatarUrl = http://example.org/avatars/mike.png
13 |
14 | *** HTTP Request ***
15 | POST /people/ HTTP/1.1
16 | Host: example.org
17 | Accept-Type: application/vnd.amundsen-uber+xml
18 | Content-Type: application/x-www-form-urlencoded
19 | Content-Length: xxx
20 |
21 | g=Mike&f=Amundsen&e=mike%40example.org&a=http%3A%2F%2Fexample.org%2Favatars%2Fmike.png
22 |
23 |
--------------------------------------------------------------------------------
/uber-apps/tasks/tasks-alps.xml:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 | Profile for simple hypermedia task list demo app.
6 |
7 |
8 |
9 |
10 |
11 |
12 |
13 |
14 |
15 |
16 |
17 |
18 |
19 |
20 |
21 |
22 |
23 |
24 |
25 |
--------------------------------------------------------------------------------
/includes/search-sample.js:
--------------------------------------------------------------------------------
1 | {
2 | "uber" :
3 | {
4 | "version" : "1.0",
5 | "data" :
6 | [
7 | {
8 | "rel" : ["self"],
9 | "url" : "http://example.org/"
10 | },
11 | {
12 | "name" : "list",
13 | "rel" : ["collection"],
14 | "url" : "http://example.org/list/"
15 | },
16 | {
17 | "name" : "search",
18 | "rel" : ["search","collection"],
19 | "url" : "http://example.org/search",
20 | "model" : "{?title}"
21 | },
22 | {
23 | "name" : "todo",
24 | "rel" : ["item","http://example.org/rels/todo"],
25 | "url" : "http://example.org/list/1",
26 | "data" :
27 | [
28 | {"name" : "title", "value" : "Clean house"},
29 | {"name" : "dueDate", "value" : "2014-05-01"}
30 | ]
31 | },
32 | {
33 | "name" : "todo",
34 | "rel" : ["item","http://example.org/rels/todo"],
35 | "url" : "http://example.org/list/2",
36 | "data" :
37 | [
38 | {"name" : "title", "value" : "Paint the fence"},
39 | {"name" : "dueDate", "value" : "2014-06-01"}
40 | ]
41 | }
42 | ]
43 | }
44 | }
45 |
--------------------------------------------------------------------------------
/includes/full-example.xml:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 |
6 |
11 |
15 |
16 |
17 | Mildred
18 | Amundsen
19 | mildred@example.org
20 | User Photo
22 |
23 |
24 | Mildred
25 | Amundsen
26 | mildred@example.org
27 | User Photo
29 |
30 |
31 |
32 |
33 |
37 |
38 |
39 | Home
40 |
41 | 123 Main
42 | Byteville
43 | MD
44 | 12345
45 |
46 |
47 |
48 | Work
49 |
50 | 456 Grand Ave.
51 | Byteville
52 | MD
53 | 12345
54 |
55 |
56 |
57 |
58 |
59 |
60 |
--------------------------------------------------------------------------------
/includes/full-example.js:
--------------------------------------------------------------------------------
1 | {
2 | "uber" :
3 | {
4 | "version" : "1.0",
5 | "data" :
6 | [
7 | {"rel" : ["self"], "url" : "http://example.org/"},
8 | {"rel" : ["profile"], "url" : "http://example.org/profiles/people-and-places"},
9 | {
10 | "id" : "people",
11 | "rel" : ["collection","http://example.org/rels/people"],
12 | "url" : "http://example.org/people/",
13 | "data" :
14 | [
15 | {
16 | "name" : "create",
17 | "rel" : ["http://example.org/rels/create"],
18 | "url" : "http://example.org/people/",
19 | "model" : "g={givenName}&f={familyName}&e={email}",
20 | "action" : "append"
21 | },
22 | {
23 | "name" : "search",
24 | "rel" : ["search","collection"],
25 | "url" : "http://example.org/people/search",
26 | "model" : "?g={givenName}&f={familyName}&e={email}"
27 | },
28 | {
29 | "name" : "person",
30 | "rel" : ["item","http://example.org/rels/person"],
31 | "url" : "http://example.org/people/1",
32 | "data" :
33 | [
34 | {"name" : "givenName", "value" : "Mike"},
35 | {"name" : "familyName", "value" : "Amundsen"},
36 | {"name" : "email", "value" : "mike@example.org"},
37 | {"name" : "avatarUrl", "transclude" : "true",
38 | "url" : "http://example.org/avatars/1",
39 | "value" : "User Photo",
40 | "accepting" : ["image/*"]
41 | }
42 | ]
43 | },
44 | {
45 | "name" : "person",
46 | "rel" : ["item","http://example.org/rels/person"],
47 | "url" : "http://example.org/people/2",
48 | "data" :
49 | [
50 | {"name" : "givenName", "value" : "Mildred"},
51 | {"name" : "familyName", "value" : "Amundsen"},
52 | {"name" : "email", "value" : "mildred@example.org"},
53 | {"name" : "avatarUrl", "transclude" : "true",
54 | "url" : "http://example.org/avatars/2",
55 | "value" : "User Photo",
56 | "accepting" : ["image/*"]
57 | }
58 | ]
59 | }
60 | ]
61 | },
62 |
63 | {
64 | "id" : "places",
65 | "rel" : ["collection","http://example.org/rels/places"],
66 | "url" : "http://example.org/places/",
67 | "data" :
68 | [
69 | {
70 | "name" : "search",
71 | "rel" : ["search","collection"],
72 | "url" : "http://example.org/places/search",
73 | "model" : "?r={addressRegion}&l={addressLocality}&p={postalCode}"
74 | },
75 | {
76 | "name" : "place",
77 | "rel" : ["item","http://example.org/rels/place"],
78 | "url" : "http://example.org/places/a",
79 | "data" :
80 | [
81 | {
82 | "name" : "name",
83 | "value" : "Home"
84 | },
85 | {
86 | "name" : "address",
87 | "data" :
88 | [
89 | {"name" : "streetAddress", "value" : "123 Main Street"},
90 | {"name" : "addressLocalitly", "value" : "Byteville"},
91 | {"name" : "addressRegion", "value" : "MD"},
92 | {"name" : "postalCode", "value" : "12345"}
93 | ]
94 | }
95 | ]
96 | },
97 | {
98 | "name" : "place",
99 | "rel" : ["item","http://example.org/rels/place"],
100 | "url" : "http://example.org/places/b",
101 | "data" :
102 | [
103 | {
104 | "name" : "name",
105 | "value" : "Work"
106 | },
107 | {
108 | "name" : "address",
109 | "data" :
110 | [
111 | {"name" : "streetAddress", "value" : "1456 Grand Ave."},
112 | {"name" : "addressLocalitly", "value" : "Byteville"},
113 | {"name" : "addressRegion", "value" : "MD"},
114 | {"name" : "postalCode", "value" : "12345"}
115 | ]
116 | }
117 | ]
118 | }
119 | ]
120 | }
121 | ]
122 | }
123 | }
124 |
125 |
--------------------------------------------------------------------------------
/uber-apps/tasks/tasks.js:
--------------------------------------------------------------------------------
1 | /* client side library for tasks */
2 |
3 | window.onload = function() {
4 | var pg;
5 | pg = thisPage();
6 | pg.init();
7 | };
8 |
9 | var thisPage = function() {
10 |
11 | var g = {};
12 | g.msg = {};
13 | g.listUrl = '/tasks/';
14 |
15 | // prime the system
16 | function init() {
17 | makeRequest(g.listUrl,'list');
18 | }
19 |
20 | /* parse the response */
21 | function showResponse() {
22 | var elm, li, i, x, coll, item, data, task;
23 |
24 | // fill in the list
25 | elm = document.getElementById('data');
26 | if(elm) {
27 | elm.innerHTML = '';
28 |
29 | coll = g.msg.getElementsByTagName('data');
30 | for(i=0,x=coll.length;i0 || showControls===true) {
265 | msg += m.listControl;
266 | msg += m.filterControl;
267 | }
268 | msg += m.addControl;
269 | msg += '';
270 |
271 | msg += '';
272 | for(i=0,x=list.length;i>.
32 | * Be compatible with multiple protocols (e.g. <>, <>, etc.)
33 | * Maintain fidelity for more than one base message format (XML, JSON, etc.)
34 |
35 | === Messages, Not Code
36 | The UBER message model is designed to be a 'message' format and not a source code format. It is optimized for cross-format use (XML and JSON) and not optimized to be directly serialized into source code or data objects. This is especially noticeable in the JSON variant of UBER. However, the UBER message model 'is' designed to make it relatively easy to write a parser that can consistently transform UBER messages into object models (and back again).
37 |
38 | === Compliance
39 | An implementation is not compliant if it fails to satisfy one or more of the MUST or REQUIRED elements. An implementation that satisfies all the MUST and REQUIRED elements as well as all the SHOULD and RECOMMENDED elements is said to be "unconditionally compliant"; one that satisfies all the MUST and REQUIRED elements but not all the SHOULD and RECOMMENDED elements is said to be "conditionally compliant."
40 |
41 | [NOTE]
42 | ====
43 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 <>.
44 | ====
45 |
46 | == The UBER Message Model
47 | The UBER message model is very minimal. There are three elements, eleven possible properties, and seven reserved string values.
48 |
49 | === Elements
50 | There are only three elements in the UBER message model:
51 |
52 | ++::
53 | The root element of all UBER messages
54 | ++::
55 | The main element in UBER messages.
56 | ++::
57 | The element that carries error details from the previous request.
58 |
59 | === Properties
60 | There are eleven properties in the UBER design:
61 |
62 | +id+::
63 | The document-wide unique identifier for this element.
64 | +name+::
65 | A document-wide non-unique identifer for this element.
66 | +rel+::
67 | Contains one or more link relation values.
68 | +url+::
69 | A resolvable URL associated with this element.
70 | +action+::
71 | The network request verb associated with this element.
72 | +transclude+::
73 | Indicates whether the content that is returned from the URL should be embedded within the currently loaded document
74 | +model+::
75 | Contains a template to be used to construct URL query strings or request bodies depending on the value in the +action+ property.
76 | +sending+::
77 | Contains one or more media type identifiers for use when sending request bodies.
78 | +accepting+::
79 | Contains one or more media type identifiers to expect when receiving request bodies.
80 | +value+::
81 | In the XML variant of the UBER mesage format, inner text of the ++ element contains the value associated with that element. In the JSON variant there is a +value+ property that contains the associated value.
82 | +version+::
83 | Indicates the UBER message version information.
84 |
85 | === Reserved Strings
86 | There are seven reserved strings used as possible values for UBER properties.
87 |
88 | Reserved strings for the +action+ property::
89 | * +append+ : An unsafe, non-idempotent request to add a new item.
90 | * +partial+ : An unsafe, non-idempotent request to modify parts of an existing item.
91 | * +read+ : A safe, idempotent request.
92 | * +remove+ : An unsafe, idempotent request to delete an existing item.
93 | * +replace+ : An unsafe, idempotent request to replace an existing item.
94 |
95 | Reserved strings for the +transclude+ property::
96 | * +true+ : embed the results of the request into the current document
97 | * +false+ : treat the associated +url+ value as a 'navigation' to a new document.
98 |
99 | === Link Relation Values
100 | There are no UBER-specific link relation values. Document authors SHOULD use registered link relation values that comply the guidance provided in RFC5988 <> and from shared public sources such as:
101 |
102 | * IANA Link Relations <>
103 | * Microformats Existing Rel Values <>
104 | * Dublin Core Metadata Element Set, Version 1.1 <>
105 |
106 | === Message Map
107 | Below is a simple `map' of the UBER message format (XML variant). Along with the three elements, there are ten properties (indicated by the `@' character). The ++ element can appear as a child element of ++ and ++ and may be nested as many times as needed.
108 |
109 | .UBER Message Model (XML)
110 | ----
111 | include::includes/message-model.xml[]
112 | ----
113 |
114 | === The ++ Element
115 | This is the root element of an UBER message. Every UBER message MUST have this as its root. The ++ element has one optional property: +version+ which carries the UBER message version information. For this release, all UBER messages SHOULD be set to the value of "1.0". If the +version+ property is missing, it SHOULD be assumed to be set to "1.0".
116 |
117 | .Example ++ Elements
118 | ----
119 |
120 |
121 | ...
122 |
123 |
124 | // JSON format
125 | {"uber" : {"version" : "1.0", ...} }
126 | ----
127 |
128 | === The ++ Element
129 | The ++ element is the key element in the model. A valid UBER message SHOULD contain at least one ++ element. If it does appear, the ++ element appears as a child of the ++ or ++ elements. The ++ element MAY be nested as many times as needed. The ++ element has the following property (all properties are OPTIONAL):
130 |
131 | +id+::
132 | The document-wide unique identifier for this element. The value of +id+ must begin with a letter ([A-Za-z]) and may be followed by any number of letters, digits ([0-9]), hyphens ("-"), underscores ("_"), colons (":"), and periods ("."). If the +id+ property is present, it SHOULD be treated as an in-document reference as described in section 3.5 of RFC3986 <>.
133 |
134 | +name+::
135 | A document-wide non-unique identifer for this element. The value of +name+ must begin with a letter ([A-Za-z]) and may be followed by any number of letters, digits ([0-9]), hyphens ("-"), underscores ("_"), colons (":"), and periods ("."). If the +name+ property is present it MAY be used as a variable in the UBER +model+ property as described in <>.
136 |
137 | +rel+::
138 | Contains a list of link relation values. These values SHOULD conform to the guidance provided in RFC5988 <>. In the XML variant the list of link relation values appears as a space-separated list. In the JSON variant the list of link realtion values appears as an array.
139 |
140 | +url+::
141 | A resolvable URL associated with this element. The value SHOULD conform to that described in RFC3986 <>.
142 |
143 | +action+::
144 | The network request verb associated with this element. The list of valid values for this element are:
145 |
146 | * +append+ : An unsafe, non-idempotent request to add a new item (e.g. +HTTP.POST+ <>)
147 | * +partial+ : An unsafe, non-idempotent request to modify parts of an existing item (e.g. +HTTP.PATCH+ <>)
148 | * +read+ : A safe, idempotent request (e.g. +HTTP.GET+ <>)
149 | * +remove+ : An unsafe, idempotent request to delete an existing item (e.g. +HTTP.DELETE+ <>)
150 | * +replace+ : An unsafe, idempotent request to replace an existing item (e.g. +HTTP.PUT+ <>)
151 |
152 | +
153 | When the ++ element has a +url+ property but no +action+ property, it SHOULD be assumed the +action+ property is set to +read+. Any value other than those listed here SHOULD be treated as +read+.
154 |
155 | +transclude+::
156 | Indicates whether the content that is returned from the URL should be embedded within the currently loaded document (+transclude="true"+) or treated as a 'navigation' to a new document (+transclude="false"+). If the property is missing, it SHOULD be assumed to be set to +false+ (e.g. 'navigation').
157 |
158 | +model+::
159 | Contains a RFC6570-compliant <> string to be used to construct URL query strings or request bodies depending on the value in the +action+ property. Variables in UBER +model+ strings SHOULD be resolved using the values from +name+ properties, but MAY come from any source available to the client application. If the +action+ property is set to +read+ or +remove+ then the +model+ is applied to the query string. If the +action+ value is set to +append+, +partial+, or +replace+ then the +model+ is applied to the request body.
160 |
161 | +sending+::
162 | Contains one or more media type identifiers for use when sending request bodies. One of the supplied identifiers SHOULD be selected as a guide when formatting the request body. For HTTP implementations, the selected identifier SHOULD be used as the value for the +Content-Type+ header. If this property is missing the setting should be assumed to be +application/x-www-form-urlencoded+ as described in RFC1867 <>.
163 | +
164 | In the XML variant the list of media-type identifiers appears as a space-separated list. In the JSON variant the list of media-type identifiers appears as an array.
165 |
166 | +accepting+::
167 | Contains one or more media type identifiers to expect when recieving request bodies. The contents of this property SHOULD indicate the formats in which the server is able to return a response body. For HTTP implementations the contents of this property SHOULD be used as the value for the +Accept+ header. If this property is missing, the setting should be assumed to be set to the same value as that of the currently loaded representation (+application/vnd.uber-amundsen+xml+ or +application/vnd.uber-amundsen+json+).
168 | +
169 | In the XML variant the list of media-type identifiers appears as a space-separated list. In the JSON variant the list of media-type identifiers appears as an array.
170 |
171 | +value+::
172 | In the XML variant of the UBER mesage format, inner text of the ++ element contains the value associated with that element.
173 | +
174 | In the JSON variant there is a +value+ property that contains the associated value. Note that the content of this field MUST NOT be a JSON object or array and MUST be one of the following scalar values (listed in Section 2.1 of RFC4627 <>):
175 | +
176 | * number
177 | * string
178 | * +false+
179 | * +true+
180 | * +null+
181 |
182 | +
183 | For both the XML and JSON variants, it is the responsibility of the document author to make sure the contents of the +value+ property are properly escaped as needed (per Section 2.4 of <> and Section 2.5 of <>).
184 |
185 | .Example ++ Elements (XML)
186 | ----
187 | include::includes/search-sample.xml[]
188 | ----
189 |
190 | .Example ++ Elements (JSON)
191 | ----
192 | include::includes/search-sample.js[]
193 | ----
194 |
195 | === The ++ Element
196 | The ++ element contains any error information returned by the server regarding the previous request. The ++ element has no properties. This is an OPTIONAL element. When present, it SHOULD contain one or more ++ child elements. It is the ++ child elements that contains error details.
197 |
198 | .Example ++ Element (XML)
199 | ----
200 | include::includes/error-sample.xml[]
201 | ----
202 |
203 | .Example ++ Element (JSON)
204 | ----
205 | include::includes/error-sample.js[]
206 | ----
207 |
208 | == Implementation Guidelines
209 | Since the UBER messsage format was designed to work with multiple application protocols (HTTP, CoAP, etc.), there needs to be some guidelines for creating a protocol-specific implementation that supports UBER documents. Below is the HTTP guidance for UBER documents. This can be used as a guide in creating (and documenting) other protocol-specific implemenations.
210 |
211 | === Supporting UBER Documents over HTTP
212 | This section decribes the details of implementing UBER support over HTTP.
213 |
214 | ==== Mapping UBER +action+ Values to HTTP Methods
215 | When implementating support for UBER documents over HTTP one of the key details is to map the value of UBER's +action+ property to HTTP methods. Table #1 below provides this mapping:
216 |
217 | .Mapping HTTP Methods to UBER +action+ and +model+ Values
218 | [grid="rows", format="csv"]
219 | [options="header"]
220 | |====
221 | UBER Action,HTTP Method, UBER Model Modifies
222 | +append+,POST, Request Body
223 | +partial+,PATCH, Request Body
224 | +read+,GET, Query String
225 | +remove+,DELETE, Query String
226 | +replace+,PUT, Request Body
227 | |====
228 |
229 | ==== Using UBER +model+ Values to create HTTP Query Strings
230 | When applied to HTTP, any +model+ value associated with a +data+ element with the +action+ property set to +read+ or +remove+ MUST be converted into a valid query string. The follwing example shows how an UBER message snippet is converted into a valid HTTP query string:
231 |
232 | .Converting an UBER +read+ Action into an HTTP Query String
233 | ----
234 | include::includes/uber-query-string.txt[]
235 | ----
236 |
237 | ==== Using UBER +model+ Values to create HTTP Request Bodies
238 | Any +model+ value associated with a +data+ element with the +action+ property set to +append+, +partial+, or +replace+ MUST be convereted into a valid HTTP request body. The follwing example shows how an UBER message snippet is converted into a valid HTTP request body:
239 |
240 | .Converting an UBER +append+ Action into an HTTP Request
241 | ----
242 | include::includes/uber-request-body.txt[]
243 | ----
244 |
245 | === Supporting UBER Documents Over other Protocols
246 | It is possible that UBER documents can be exchanged using a protocol other than HTTP. In that case, it is the responsibility of the implementor to provide a guideline document that covers the same material included in the "Implementation Guidelines" of the UBER Message specification.
247 |
248 | == Message Examples
249 | UBER messages may appear in XML or JSON formats. Below are examples of each.
250 |
251 | === XML Example
252 | Below is an XML Example of an UBER message.
253 |
254 | .XML Example
255 | ----
256 | include::includes/full-example.xml[]
257 | ----
258 |
259 | === JSON Example
260 | Below is a JSON Example of an UBER message.
261 |
262 | .UBER JSON Example
263 | ----
264 | include::includes/full-example.js[]
265 | ----
266 |
267 | == Extensibility
268 | This document describes the UBER message format markup vocabulary. Markup from other vocabularies ("foreign markup") can be used in an UBER document. Any extensions to the UBER Hypermedia vocabulary MUST not redefine any objects (or their properties), arrays, properties, link relations, or data types defined in this document. Clients that do not recognize extensions to the UBER vocabulary SHOULD ignore them.
269 |
270 | The details of designing and implementing UBER extensions is beyond the scope of this document.
271 |
272 | [NOTE]
273 | ====
274 | It is possible that future forward-compatible modifications to this specification will include new objects, arrays, properties, link-relations, and data types. Extension designers should take care to prevent future modifications from breaking or redefining those extensions.
275 | ====
276 |
277 | == IANA Considerations
278 | Below are the related IANA considerations for this media type design.
279 |
280 | === XML Media Type Registration
281 | +++[pending submission]+++
282 |
283 | === JSON Media Type Registration
284 | +++[pending submission]+++
285 |
286 | === Security Considerations
287 | The XML variant of the UBER message format shares security issues common to all XML content types. It does not provide executable content. Information contained in UBER documents do not require privacy or integrity services.
288 |
289 | The JSON variant of the UBER message format shares security issues common to all JSON content types. See RFC4627 Section #6 <> for additional information. The UBER message format does not provide executable content. Information contained in UBER documents do not require privacy or integrity services.
290 |
291 | === Internationalization Considerations
292 | The UBER message format does not have any internationalization considerations other than those which are discussed in referenced RFC documents (see below).
293 |
294 | == References
295 | Below are the references used in this document.
296 |
297 | === Normative References
298 | * [[rfc1867]] [RFC1867] Nebel, E., Masinter, L., "Form-based File Upload in HTML", November 1995, http://tools.ietf.org/search/rfc1867
299 | * [[rfc2119]] [RFC2119] Bradner, S.,"Key words for use in RFCs to Indicate Requirement Levels", March 1997, http://tools.ietf.org/html/rfc2119
300 | * [[rfc2616]] [RFC2616] Fielding, R, et al, "Hypertext Transfer Protocol -- HTTP/1.1", June 1999, https://tools.ietf.org/html/rfc2616
301 | * [[rfc3986]] [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,"Uniform Resource Identifier (URI): Generic Syntax", January 2005, http://tools.ietf.org/html/rfc3986
302 | * [[rfc4627]] [RFC4627] D. Crockford, "The application/json Media Type for JavaScript Object Notation (JSON)", July 2006, http://tools.ietf.org/html/rfc4627
303 | * [[rfc5789]] [RFC5789] Dusseault, L., Snell, J., "PATCH Method for HTTP", March 2010, https://tools.ietf.org/html/rfc5789
304 | * [[rfc5988]] [RFC5988] Nottingham, M., "Web Linking", October 2010, http://tools.ietf.org/html/rfc5988
305 | * [[rfc6570]] [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., Orchard, D., "URI Template", March 2012, http://tools.ietf.org/html/rfc6570
306 | * [[REC-XML]] [REC-XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., Yergeau, F., "Extensible Markup Language (XML) 1.0 (Fifth Edition)", November 2008, http://www.w3.org/TR/REC-xml/
307 |
308 | === Informative References
309 | * [[hfactor]] [HFactor] Amundsen, M. "H Factor", May 2010, http://amundsen.com/hypermedia/hfactor/
310 | * [[iana-rel]] [IANA-REL] "Link Relations, December 2013, http://www.iana.org/assignments/link-relations/link-relations.xhtml
311 | * [[mf-rel]] [MF-REL] "Microformat Existing Rel Values", February 2014, http://microformats.org/wiki/existing-rel-values
312 | * [[dc-rel]] [DC-REL] "Dublin Core Metadata Element Set, Version 1.1", June 2012, http://dublincore.org/documents/dces/
313 | * [[idcoap18]] [CoAP] "Shelby, Z., Hartke, K., Bormann, C., "Constrained Application Protocol (CoAP)", June 28, 2013, https://tools.ietf.org/html/draft-ietf-core-coap-18
314 |
315 | == Acknowledgements
316 | The author would like to thank everyone who commented upon,
317 | encouraged, and gave feedback to this specification,
318 | especially
319 | Cédric Brancourt,
320 | Mark W. Foster,
321 | Steve Klabnik,
322 | Matthew McClure,
323 | Stephen Mizell,
324 | Irakli Nadareishvili.
325 |
326 |
327 | .
328 |
--------------------------------------------------------------------------------