idnits 2.17.1 draft-kelly-json-hal-03.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 (July 1, 2012) is 4310 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-wilde-profile-link-02 ** 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 (~~), 2 warnings (==), 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 July 1, 2012 5 Expires: January 2, 2013 7 JSON Hypermedia API Language 8 draft-kelly-json-hal-03 10 Abstract 12 This document proposes a media type for representing resources and 13 their relations as hypermedia. 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 January 2, 2013. 32 Copyright Notice 34 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . . . . . . 5 56 5. Link Objects . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 5.1. href . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 5.2. templated . . . . . . . . . . . . . . . . . . . . . . . . 5 59 5.3. type . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 5.4. name . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 5.5. profile . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 5.6. title . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 5.7. hreflang . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 6. Example Document . . . . . . . . . . . . . . . . . . . . . . . 6 65 7. Media Type Parameters . . . . . . . . . . . . . . . . . . . . 8 66 7.1. profile . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 8. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 8 68 8.1. Self Link . . . . . . . . . . . . . . . . . . . . . . . . 8 69 8.2. Link relations . . . . . . . . . . . . . . . . . . . . . . 8 70 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 72 11. Normative References . . . . . . . . . . . . . . . . . . . . . 9 73 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 9 74 Appendix B. Frequently Asked Questions . . . . . . . . . . . . . 10 75 B.1. How should a client know the 76 meaning/structure/semantics/type of a resource? . . . . . 10 77 B.2. Where can I find libraries for working with HAL? . . . . . 10 78 B.3. Why are the reserved properties prefixed with an 79 underscore? . . . . . . . . . . . . . . . . . . . . . . . 10 80 B.4. Are all underscore-prefixed properties reserved? . . . . . 10 81 B.5. Why does HAL have no forms? . . . . . . . . . . . . . . . 10 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 84 1. Introduction 86 There is an emergence of non-HTML HTTP applications ("Web APIs") 87 which use hypermedia to direct clients around their resources. 89 The JSON Hypermedia API Language (HAL) is a standard which 90 establishes conventions for expressing hypermedia controls, such as 91 links, with JSON [RFC4627]. 93 HAL is a generic media type with which Web APIs can be developed and 94 exposed as series of links. Clients of these APIs can select links 95 by their link relation type and traverse them in order to progress 96 through the application. 98 HAL's conventions result in a uniform interface for serving and 99 consuming hypermedia, enabling the creation of general-purpose 100 libraries that can be re-used on any API utilising HAL. 102 The primary design goals of HAL are generality and simplicity. HAL 103 can be applied to many different domains, and imposes the minimal 104 amount of structure necessary to cover the key requirements of a 105 hypermedia API. 107 2. Requirements 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119]. 113 3. HAL Documents 115 A HAL Document uses the format described in [RFC4627] and has the 116 media type "application/hal+json". 118 Its root object MUST be a Resource Object. 120 For example: 122 GET /orders/523 HTTP/1.1 123 Host: example.org 124 Accept: application/hal+json 126 HTTP/1.1 200 OK 127 Content-Type: application/hal+json 129 { 130 "_links": { 131 "self": { "href": "/orders/523" }, 132 "warehouse": { "href": "/warehouse/56" }, 133 "invoice": { "href": "/invoices/873" } 134 }, 135 "currency": "USD", 136 "status": "shipped", 137 "total": 10.20 138 } 140 Here, we have a HAL document representing an order resource with the 141 URI "/orders/523". It has "warehouse" and "invoice" links, and its 142 own state in the form of "currency", "status", and "total" 143 properties. 145 4. Resource Objects 147 A Resource Object represents a resource. 149 It has two reserved properties: 150 (1) "_links": contains links to other resources. 151 (2) "_embedded": contains embedded resources. 153 All other properties MUST be valid JSON, and represent the current 154 state of the resource. 156 4.1. Reserved Properties 158 4.1.1. _links 160 The reserved "_links" property is OPTIONAL. 162 It is an object whose property names are link relation types (as 163 defined by [RFC5988]) and values are either a Link Object or an array 164 of Link Objects. The subject resource of these links is the Resource 165 Object of which the containing "_links" object is a property. 167 4.1.2. _embedded 169 The reserved "_embedded" property is OPTIONAL 171 It is an object whose property names are link relation types (as 172 defined by [RFC5988]) and values are either a Resource Object or an 173 array of Resource Objects. 175 5. Link Objects 177 A Link Object represents a hyperlink from the containing resource to 178 a URI. It has the following properties: 180 5.1. href 182 The "href" property is REQUIRED. 184 Its value is either a URI [RFC3986] or a URI Template [RFC6570]. 186 If the value is a URI Template then the Link Object SHOULD have a 187 "templated" attribute whose value is true. 189 5.2. templated 191 The "templated" property is OPTIONAL. 193 Its value is boolean and SHOULD be true when the Link Object's "href" 194 property is a URI Template. 196 Its value SHOULD be considered false if it is undefined or any other 197 value than true. 199 5.3. type 201 The "type" property is OPTIONAL. 203 Its value is a string used as a hint to indicate the media type 204 expected when dereferencing the target resource. 206 5.4. name 208 The "name" property is OPTIONAL. 210 Its value MAY be used as a secondary key for selecting Link Objects 211 which share the same relation type. 213 5.5. profile 215 The "profile" property is OPTIONAL. 217 Its value is a string which is a URI that hints about the profile (as 218 defined by [I-D.wilde-profile-link]) of the target resource. 220 5.6. title 222 The "title" property is OPTIONAL. 224 Its value is a string and is intended for labelling the link with a 225 human-readable identifier (as defined by [RFC5988]). 227 5.7. hreflang 229 The "hreflang" property is OPTIONAL. 231 Its value is a string and is intended for indicating the language of 232 the target resource (as defined by [RFC5988]). 234 6. Example Document 236 The following is an example document representing a list of orders 237 GET /orders HTTP/1.1 238 Host: example.org 239 Accept: application/hal+json 241 HTTP/1.1 200 OK 242 Content-Type: application/hal+json 244 { 245 "_links": { 246 "self": { "href": "/orders" }, 247 "next": { "href": "/orders?page=2" }, 248 "find": { "href": "/orders{?id}", "templated": true } 249 }, 250 "_embedded": { 251 "orders": [{ 252 "_links": { 253 "self": { "href": "/orders/123" }, 254 "basket": { "href": "/baskets/98712" }, 255 "customer": { "href": "/customers/7809" } 256 }, 257 "total": 30.00, 258 "currency": "USD", 259 "status": "shipped", 260 },{ 261 "_links": { 262 "self": { "href": "/orders/124" }, 263 "basket": { "href": "/baskets/97213" }, 264 "customer": { "href": "/customers/12369" } 265 }, 266 "total": 20.00, 267 "currency": "USD", 268 "status": "processing" 269 }] 270 }, 271 "currentlyProcessing": 14, 272 "shippedToday": 20 273 } 275 Here, the order list document provides a "next" link directing to the 276 next page, and a "find" link containing a URI Template which can be 277 expanded with an 'id' variable to go directly to a specific order. 279 It also has two embedded resources, "orders". Each of these has its 280 own links to the associated "basket" and "customer" resources, and 281 properties showing their "total", "currency" and "status". 283 Additionally, the order list resource has its own properties 284 "currentlyProcessing" and "shippedToday". 286 7. Media Type Parameters 288 7.1. profile 290 The media type identifier application/hal+json MAY also include an 291 additional "profile" parameter (as defined by 292 [I-D.wilde-profile-link]) 294 HAL documents that are served with the "profile" parameter still 295 SHOULD include a "profile" link belonging to the root resource. 297 8. Recommendations 299 8.1. Self Link 301 Each Resource Object SHOULD contain a 'self' link that corresponds 302 with the IANA registered 'self' relation (as defined by [RFC5988]) 303 whose target is the resource's URI. 305 8.2. Link relations 307 Custom link relation types (Extension Relation Types in [RFC5988]) 308 SHOULD be URIs that when dereferenced in a web browser provide 309 relevant documentation, in the form of an HTML page, about the 310 meaning and/or behaviour of the target Resource. This will improve 311 the discoverability of the API. 313 The CURIE Syntax [W3C.NOTE-curie-20101216] MAY be used for brevity 314 for these URIs. A CURIE is established within a HAL document via a 315 "curie" link on the root Resource Object. This link contains a URI 316 Template with the token 'rel', and is named via the "name" property 317 of the Link Object. 319 { 320 "_links": { 321 "self": { "href": "/orders" }, 322 "curie": { 323 "name": "acme", 324 "href": "http://docs.acme.com/relations/{rel}", 325 "templated": true 326 }, 327 "acme:widgets": { "href": "/widgets" } 328 } 329 } 331 The above demonstrates the relation 332 "http://docs.acme.com/relations/widgets" being abbreviated to "acme: 334 widgets" via CURIE syntax. 336 9. Security Considerations 338 TBD 340 10. IANA Considerations 342 TBD 344 11. Normative References 346 [I-D.wilde-profile-link] 347 Wilde, E., "The 'profile' Link Relation Type", 348 draft-wilde-profile-link-02 (work in progress), June 2012. 350 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 351 Requirement Levels", BCP 14, RFC 2119, March 1997. 353 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 354 Resource Identifier (URI): Generic Syntax", STD 66, 355 RFC 3986, January 2005. 357 [RFC4627] Crockford, D., "The application/json Media Type for 358 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 360 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. 362 [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., 363 and D. Orchard, "URI Template", RFC 6570, March 2012. 365 [W3C.NOTE-curie-20101216] 366 McCarron, S. and M. Birbeck, "CURIE Syntax 1.0", World 367 Wide Web Consortium NOTE NOTE-curie-20101216, 368 December 2010, 369 . 371 [1] 373 Appendix A. Acknowledgements 375 Thanks to Darrel Miller, Mike Amundsen, and everyone in hal-discuss 376 for their suggestions and feedback. 378 The author takes all responsibility for errors and omissions. 380 Appendix B. Frequently Asked Questions 382 B.1. How should a client know the meaning/structure/semantics/type of a 383 resource? 385 There are two main approaches to solving this problem. Both involve 386 exposing additional documentation describing the resource which may 387 be human and/or machine readable (i.e. an HTML page and/or a JSON 388 Schema document). The difference between the two approaches is in 389 where that URI is shared with the client, which is either: 390 (1) The URI that was the preceding link relation type. 391 (2) A 'profile' link from the resource itself. 393 B.2. Where can I find libraries for working with HAL? 395 A list of libraries is maintained and published at the HAL Home 396 Page [1] 398 B.3. Why are the reserved properties prefixed with an underscore? 400 We elected for a prefix character to minimize risk of collisions with 401 properties that represent the resource's state, and underscore was 402 the character picked. 404 Another reason for prefixing the reserved properties is to make it 405 visually apparent that the reserved properties are distinct from 406 standard properties belonging to the resource. 408 B.4. Are all underscore-prefixed properties reserved? 410 No, HAL only reserves the names detailed in this specification. 412 B.5. Why does HAL have no forms? 414 Omitting forms from HAL was an intentional design decision that was 415 made to keep it focused on linking for APIs. HAL is therefore a good 416 candidate for use as a base media type on which to build more complex 417 capabilities. An additional media type is planned for the future 418 which will add form-like controls on top of HAL. 420 Author's Address 422 Mike Kelly 423 Stateless 425 Email: mike@stateless.co 426 URI: http://stateless.co/