idnits 2.17.1 draft-kelly-json-hal-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 11, 2016) is 2900 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4627 (Obsoleted by RFC 7158, RFC 7159) ** Obsolete normative reference: RFC 5988 (Obsoleted by RFC 8288) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Kelly 3 Internet-Draft Stateless 4 Intended status: Informational May 11, 2016 5 Expires: November 12, 2016 7 JSON Hypertext Application Language 8 draft-kelly-json-hal-08 10 Abstract 12 This document proposes a media type for representing resources and 13 their relations with hyperlinks. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on November 12, 2016. 32 Copyright Notice 34 Copyright (c) 2016 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3. HAL Documents . . . . . . . . . . . . . . . . . . . . . . . . 3 52 4. Resource Objects . . . . . . . . . . . . . . . . . . . . . . 4 53 4.1. Reserved Properties . . . . . . . . . . . . . . . . . . . 4 54 4.1.1. _links . . . . . . . . . . . . . . . . . . . . . . . 4 55 4.1.2. _embedded . . . . . . . . . . . . . . . . . . . . . . 4 56 5. Link Objects . . . . . . . . . . . . . . . . . . . . . . . . 4 57 5.1. href . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 5.2. templated . . . . . . . . . . . . . . . . . . . . . . . . 5 59 5.3. type . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 5.4. deprecation . . . . . . . . . . . . . . . . . . . . . . . 5 61 5.5. name . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 5.6. profile . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 5.7. title . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 5.8. hreflang . . . . . . . . . . . . . . . . . . . . . . . . 6 65 6. Example Document . . . . . . . . . . . . . . . . . . . . . . 6 66 7. Media Type Parameters . . . . . . . . . . . . . . . . . . . . 8 67 7.1. profile . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 8. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 8 69 8.1. Self Link . . . . . . . . . . . . . . . . . . . . . . . . 8 70 8.2. Link relations . . . . . . . . . . . . . . . . . . . . . 8 71 8.3. Hypertext Cache Pattern . . . . . . . . . . . . . . . . . 9 72 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 73 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 74 11. Normative References . . . . . . . . . . . . . . . . . . . . 10 75 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 10 76 Appendix B. Frequently Asked Questions . . . . . . . . . . . . . 10 77 B.1. How should a client know the 78 meaning/structure/semantics/type of a resource? . . . . . 11 79 B.2. Where can I find libraries for working with HAL? . . . . 11 80 B.3. Why are the reserved properties prefixed with an 81 underscore? . . . . . . . . . . . . . . . . . . . . . . . 11 82 B.4. Are all underscore-prefixed properties reserved? . . . . 11 83 B.5. Why does HAL have no forms? . . . . . . . . . . . . . . . 11 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 86 1. Introduction 88 There is an emergence of non-HTML HTTP applications ("Web APIs") 89 which use hyperlinks to direct clients around their resources. 91 The JSON Hypertext Application Language (HAL) is a standard which 92 establishes conventions for expressing hypermedia controls, such as 93 links, with JSON [RFC4627]. 95 HAL is a generic media type with which Web APIs can be developed and 96 exposed as series of links. Clients of these APIs can select links 97 by their link relation type and traverse them in order to progress 98 through the application. 100 HAL's conventions result in a uniform interface for serving and 101 consuming hypermedia, enabling the creation of general-purpose 102 libraries that can be re-used on any API utilising HAL. 104 The primary design goals of HAL are generality and simplicity. HAL 105 can be applied to many different domains, and imposes the minimal 106 amount of structure necessary to cover the key requirements of a 107 hypermedia Web API. 109 2. Requirements 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. 115 3. HAL Documents 117 A HAL Document uses the format described in [RFC4627] and has the 118 media type "application/hal+json". 120 Its root object MUST be a Resource Object. 122 For example: 124 GET /orders/523 HTTP/1.1 125 Host: example.org 126 Accept: application/hal+json 128 HTTP/1.1 200 OK 129 Content-Type: application/hal+json 131 { 132 "_links": { 133 "self": { "href": "/orders/523" }, 134 "warehouse": { "href": "/warehouse/56" }, 135 "invoice": { "href": "/invoices/873" } 136 }, 137 "currency": "USD", 138 "status": "shipped", 139 "total": 10.20 140 } 141 Here, we have a HAL document representing an order resource with the 142 URI "/orders/523". It has "warehouse" and "invoice" links, and its 143 own state in the form of "currency", "status", and "total" 144 properties. 146 4. Resource Objects 148 A Resource Object represents a resource. 150 It has two reserved properties: 152 (1) "_links": contains links to other resources. 154 (2) "_embedded": contains embedded resources. 156 All other properties MUST be valid JSON, and represent the current 157 state of the resource. 159 4.1. Reserved Properties 161 4.1.1. _links 163 The reserved "_links" property is OPTIONAL. 165 It is an object whose property names are link relation types (as 166 defined by [RFC5988]) and values are either a Link Object or an array 167 of Link Objects. The subject resource of these links is the Resource 168 Object of which the containing "_links" object is a property. 170 4.1.2. _embedded 172 The reserved "_embedded" property is OPTIONAL 174 It is an object whose property names are link relation types (as 175 defined by [RFC5988]) and values are either a Resource Object or an 176 array of Resource Objects. 178 Embedded Resources MAY be a full, partial, or inconsistent version of 179 the representation served from the target URI. 181 5. Link Objects 183 A Link Object represents a hyperlink from the containing resource to 184 a URI. It has the following properties: 186 5.1. href 188 The "href" property is REQUIRED. 190 Its value is either a URI [RFC3986] or a URI Template [RFC6570]. 192 If the value is a URI Template then the Link Object SHOULD have a 193 "templated" attribute whose value is true. 195 5.2. templated 197 The "templated" property is OPTIONAL. 199 Its value is boolean and SHOULD be true when the Link Object's "href" 200 property is a URI Template. 202 Its value SHOULD be considered false if it is undefined or any other 203 value than true. 205 5.3. type 207 The "type" property is OPTIONAL. 209 Its value is a string used as a hint to indicate the media type 210 expected when dereferencing the target resource. 212 5.4. deprecation 214 The "deprecation" property is OPTIONAL. 216 Its presence indicates that the link is to be deprecated (i.e. 217 removed) at a future date. Its value is a URL that SHOULD provide 218 further information about the deprecation. 220 A client SHOULD provide some notification (for example, by logging a 221 warning message) whenever it traverses over a link that has this 222 property. The notification SHOULD include the deprecation property's 223 value so that a client manitainer can easily find information about 224 the deprecation. 226 5.5. name 228 The "name" property is OPTIONAL. 230 Its value MAY be used as a secondary key for selecting Link Objects 231 which share the same relation type. 233 5.6. profile 235 The "profile" property is OPTIONAL. 237 Its value is a string which is a URI that hints about the profile (as 238 defined by [I-D.wilde-profile-link]) of the target resource. 240 5.7. title 242 The "title" property is OPTIONAL. 244 Its value is a string and is intended for labelling the link with a 245 human-readable identifier (as defined by [RFC5988]). 247 5.8. hreflang 249 The "hreflang" property is OPTIONAL. 251 Its value is a string and is intended for indicating the language of 252 the target resource (as defined by [RFC5988]). 254 6. Example Document 256 The following is an example document representing a list of orders 257 GET /orders HTTP/1.1 258 Host: example.org 259 Accept: application/hal+json 261 HTTP/1.1 200 OK 262 Content-Type: application/hal+json 264 { 265 "_links": { 266 "self": { "href": "/orders" }, 267 "next": { "href": "/orders?page=2" }, 268 "find": { "href": "/orders{?id}", "templated": true } 269 }, 270 "_embedded": { 271 "orders": [{ 272 "_links": { 273 "self": { "href": "/orders/123" }, 274 "basket": { "href": "/baskets/98712" }, 275 "customer": { "href": "/customers/7809" } 276 }, 277 "total": 30.00, 278 "currency": "USD", 279 "status": "shipped", 280 },{ 281 "_links": { 282 "self": { "href": "/orders/124" }, 283 "basket": { "href": "/baskets/97213" }, 284 "customer": { "href": "/customers/12369" } 285 }, 286 "total": 20.00, 287 "currency": "USD", 288 "status": "processing" 289 }] 290 }, 291 "currentlyProcessing": 14, 292 "shippedToday": 20 293 } 295 Here, the order list document provides a "next" link directing to the 296 next page, and a "find" link containing a URI Template which can be 297 expanded with an 'id' variable to go directly to a specific order. 299 It also has two embedded resources, "orders". Each of these has its 300 own links to the associated "basket" and "customer" resources, and 301 properties showing their "total", "currency" and "status". 303 Additionally, the order list resource has its own properties 304 "currentlyProcessing" and "shippedToday". 306 7. Media Type Parameters 308 7.1. profile 310 The media type identifier application/hal+json MAY also include an 311 additional "profile" parameter (as defined by 312 [I-D.wilde-profile-link]) 314 HAL documents that are served with the "profile" parameter still 315 SHOULD include a "profile" link belonging to the root resource. 317 8. Recommendations 319 8.1. Self Link 321 Each Resource Object SHOULD contain a 'self' link that corresponds 322 with the IANA registered 'self' relation (as defined by [RFC5988]) 323 whose target is the resource's URI. 325 8.2. Link relations 327 Custom link relation types (Extension Relation Types in [RFC5988]) 328 SHOULD be URIs that when dereferenced in a web browser provide 329 relevant documentation, in the form of an HTML page, about the 330 meaning and/or behaviour of the target Resource. This will improve 331 the discoverability of the API. 333 The CURIE Syntax [W3C.NOTE-curie-20101216] MAY be used for brevity 334 for these URIs. CURIEs are established within a HAL document via a 335 set of Link Objects with the relation type "curies" on the root 336 Resource Object. These links contain a URI Template with the token 337 'rel', and are named via the "name" property. 339 { 340 "_links": { 341 "self": { "href": "/orders" }, 342 "curies": [{ 343 "name": "acme", 344 "href": "http://docs.acme.com/relations/{rel}", 345 "templated": true 346 }], 347 "acme:widgets": { "href": "/widgets" } 348 } 349 } 351 The above demonstrates the relation "http://docs.acme.com/relations/ 352 widgets" being abbreviated to "acme:widgets" via CURIE syntax. 354 8.3. Hypertext Cache Pattern 356 The "hypertext cache pattern" allows servers to use embedded 357 resources to dynamically reduce the number of requests a client 358 makes, improving the efficiency and performance of the application. 360 Clients MAY be automated for this purpose so that, for any given link 361 relation, they will read from an embedded resource (if present) in 362 preference to traversing a link. 364 To activate this client behaviour for a given link, servers SHOULD 365 add an embedded resource into the representation with the same 366 relation. 368 Servers SHOULD NOT entirely "swap out" a link for an embedded 369 resource (or vice versa) because client support for this technique is 370 OPTIONAL. 372 The following examples shows the hypertext cache pattern applied to 373 an "author" link: 375 Before: 377 { 378 "_links": { 379 "self": { "href": "/books/the-way-of-zen" }, 380 "author": { "href": "/people/alan-watts" } 381 } 382 } 384 After: 386 { 387 "_links": { 388 "self": { "href": "/blog-post" }, 389 "author": { "href": "/people/alan-watts" } 390 }, 391 "_embedded": { 392 "author": { 393 "_links": { "self": { "href": "/people/alan-watts" } }, 394 "name": "Alan Watts", 395 "born": "January 6, 1915", 396 "died": "November 16, 1973" 397 } 398 } 399 } 401 9. Security Considerations 403 TBD 405 10. IANA Considerations 407 TBD 409 11. Normative References 411 [I-D.wilde-profile-link] 412 Wilde, E., "The 'profile' Link Relation Type", draft- 413 wilde-profile-link-04 (work in progress), October 2012. 415 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 416 Requirement Levels", BCP 14, RFC 2119, March 1997. 418 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 419 Resource Identifier (URI): Generic Syntax", STD 66, RFC 420 3986, January 2005. 422 [RFC4627] Crockford, D., "The application/json Media Type for 423 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 425 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. 427 [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., 428 and D. Orchard, "URI Template", RFC 6570, March 2012. 430 [W3C.NOTE-curie-20101216] 431 Birbeck, M. and S. McCarron, "CURIE Syntax 1.0", World 432 Wide Web Consortium NOTE NOTE-curie-20101216, December 433 2010, . 435 Appendix A. Acknowledgements 437 Thanks to Darrel Miller, Mike Amundsen, and everyone in hal-discuss 438 for their suggestions and feedback. 440 The author takes all responsibility for errors and omissions. 442 Appendix B. Frequently Asked Questions 443 B.1. How should a client know the meaning/structure/semantics/type of a 444 resource? 446 There are two main approaches to solving this problem. Both involve 447 exposing additional documentation describing the resource which may 448 be human and/or machine readable (i.e. an HTML page and/or a JSON 449 Schema document). The difference between the two approaches is in 450 where that URI is shared with the client, which is either: 452 (1) The URI that was the preceding link relation type. 454 (2) A 'profile' link from the resource itself. 456 B.2. Where can I find libraries for working with HAL? 458 A list of libraries is maintained here: http://stateless.co/ 459 hal_specification.html 461 B.3. Why are the reserved properties prefixed with an underscore? 463 We elected for a prefix character to minimise risk of collisions with 464 properties that represent the resource's state, and underscore was 465 the character picked. 467 Another reason for prefixing the reserved properties is to make it 468 visually apparent that the reserved properties are distinct from 469 standard properties belonging to the resource. 471 B.4. Are all underscore-prefixed properties reserved? 473 No, HAL only reserves the names detailed in this specification. 475 B.5. Why does HAL have no forms? 477 Omitting forms from HAL was an intentional design decision that was 478 made to keep it focused on linking for APIs. HAL is therefore a good 479 candidate for use as a base media type on which to build more complex 480 capabilities. An additional media type is planned for the future 481 which will add form-like controls on top of HAL. 483 Author's Address 485 Mike Kelly 486 Stateless 488 Email: mike@stateless.co 489 URI: http://stateless.co/