idnits 2.17.1 draft-nottingham-json-home-02.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 13, 2012) is 4243 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-19 ** Obsolete normative reference: RFC 4627 (Obsoleted by RFC 7158, RFC 7159) ** Obsolete normative reference: RFC 5988 (Obsoleted by RFC 8288) == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p4-conditional-19 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p5-range-19 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p7-auth-19 == Outdated reference: A later version (-18) exists of draft-snell-http-prefer-12 -- Obsolete informational reference (is this intentional?): RFC 4288 (Obsoleted by RFC 6838) Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Nottingham 3 Internet-Draft September 13, 2012 4 Intended status: Informational 5 Expires: March 17, 2013 7 Home Documents for HTTP APIs 8 draft-nottingham-json-home-02 10 Abstract 12 This document proposes a "home document" format for non-browser HTTP 13 clients. 15 Note to Readers 17 This draft should be discussed on the apps-discuss mailing list [1]. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on March 17, 2013. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. JSON Home Documents . . . . . . . . . . . . . . . . . . . . . 3 56 4. Resource Objects . . . . . . . . . . . . . . . . . . . . . . . 5 57 4.1. Resolving Templated Links . . . . . . . . . . . . . . . . 5 58 5. Resource Hints . . . . . . . . . . . . . . . . . . . . . . . . 6 59 5.1. allow . . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 5.2. representations . . . . . . . . . . . . . . . . . . . . . 7 61 5.3. accept-patch . . . . . . . . . . . . . . . . . . . . . . . 7 62 5.4. accept-post . . . . . . . . . . . . . . . . . . . . . . . 7 63 5.5. accept-put . . . . . . . . . . . . . . . . . . . . . . . . 7 64 5.6. accept-ranges . . . . . . . . . . . . . . . . . . . . . . 8 65 5.7. prefer . . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 5.8. docs . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 5.9. precondition-req . . . . . . . . . . . . . . . . . . . . . 8 68 5.10. auth-req . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 5.11. status . . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 6. Creating and Serving Home Documents . . . . . . . . . . . . . 9 71 6.1. Managing Change in Home Documents . . . . . . . . . . . . 9 72 6.2. Evolving and Mixing APIs with Home Documents . . . . . . . 10 73 6.3. Documenting APIs that use Home Documents . . . . . . . . . 10 74 7. Consuming Home Documents . . . . . . . . . . . . . . . . . . . 10 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 76 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 79 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 80 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12 81 Appendix B. Frequently Asked Questions . . . . . . . . . . . . . 13 82 B.1. Why not Microformats? . . . . . . . . . . . . . . . . . . 13 83 B.2. What about authentication? . . . . . . . . . . . . . . . . 13 84 B.3. What about 'Faults' (i.e., errors)? . . . . . . . . . . . 13 85 B.4. How Do I find the XML Schema / JSON Schema / etc. for 86 a particular media type? . . . . . . . . . . . . . . . . . 13 87 B.5. How do I express complex query arguments? . . . . . . . . 14 88 Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . . 14 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 91 1. Introduction 93 There is an emerging preference for non-browser Web applications 94 (colloquially, "HTTP APIs") to use a link-driven approach to their 95 interactions to assure loose coupling, thereby enabling extensibility 96 and API evolution. 98 This is based upon experience with previous APIs that specified 99 static URI paths (such as 100 "http://api.example.com/v1.0/widgets/abc123/properties") have 101 resulted in brittle, tight coupling between clients and servers. 103 Sometimes, these APIs were documented by a document format like 104 WADL [2] that is used as a design time description; i.e., the URIs 105 and other information they describe are "baked into" client 106 implementations. 108 In contrast, a "follow your nose" API advertises the resources 109 available to clients using link relations [RFC5988] and the formats 110 they support using internet media types [RFC4288]. A client can then 111 decide - at run time - which resources to interact with based upon 112 its capabilities (as described by link relations), and the server can 113 safely add new resources and formats without disturbing clients that 114 are not yet aware of them. 116 As such, the client needs to be able to discover this information 117 quickly and efficiently use it to interact with the server. Just as 118 with a human-targeted home page for a site, we can create a "home 119 document" for a HTTP API that describes it to non-browser clients. 121 Of course, an HTTP API might use any format to do so; however, there 122 are advantages to having a standard home document format. This 123 specification suggests one for consideration, using the JSON format 124 [RFC4627]. 126 2. Requirements 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in [RFC2119]. 132 3. JSON Home Documents 134 A JSON Home Document uses the format described in [RFC4627] and has 135 the media type "application/json-home". 137 Its content consists of a root object with a "resources" property, an 138 object whose names are link relation types (as defined by [RFC5988]), 139 and values are Resource Objects, defined below. 141 For example: 143 GET / HTTP/1.1 144 Host: example.org 145 Accept: application/json-home 147 HTTP/1.1 200 OK 148 Content-Type: application/json-home 149 Cache-Control: max-age=3600 150 Connection: close 152 { 153 "resources": { 154 "http://example.org/rel/widgets": { 155 "href": "/widgets/" 156 }, 157 "http://example.org/rel/widget": { 158 "href-template": "/widgets/{widget_id}", 159 "href-vars": { 160 "widget_id": "http://example.org/param/widget" 161 }, 162 "hints": { 163 "allow": ["GET", "PUT", "DELETE", "PATCH"], 164 "representations": ["application/json"], 165 "accept-patch": ["application/json-patch"], 166 "accept-post": ["application/xml"], 167 "accept-ranges": ["bytes"] 168 } 169 } 170 } 171 } 173 Here, we have a home document that links to a resource, "/widgets/" 174 with the relation "http://example.org/rel/widgets". It also links to 175 an undefined number of resources with the relation type 176 "http://example.org/rel/widget" using a URI Template [RFC6570], along 177 with a mapping of several identifiers to specific variables for use 178 in that template. 180 It also gives several hints about interacting with the latter 181 "widget" resources, including the HTTP methods usable with them, the 182 patch formats they accept, and the fact that they support partial 183 requests [I-D.ietf-httpbis-p5-range] using the "bytes" range- 184 specifier. 186 It gives no such hints about the "widgets" resource. This does not 187 mean that it (for example) doesn't support any HTTP methods; it means 188 that the client will need to discover this by interacting with the 189 resource, and/or examining the documentation for its link relation 190 type. 192 Note that the properties of a "resources" object MUST be unique; 193 i.e., one Resource Object per relation type. 195 4. Resource Objects 197 A Resource Object links to resources of the defined type using one of 198 two mechanisms; either a direct link (in which case there is exactly 199 one resource of that relation type associated with the API), or a 200 templated link, in which case there are zero to many such resources. 202 Resource Objects MUST have only and exactly one of the "href" and 203 "href-template" properties. 205 Direct links are indicated with an "href" property, whose value is a 206 URI [RFC3986]. 208 Templated links are indicated with an "href-template" property, whose 209 value is a URI Template [RFC6570]. When "href-template" is present, 210 the Resource Object MUST have a "href-vars" property; see "Resolving 211 Templated Links". 213 In both forms, the links that "href" and "href-template" refer to are 214 URI-references [RFC3986] whose base URI is that of the JSON Home 215 Document itself. 217 Resource Objects MAY also have a "hints" property, whose value is an 218 object that uses named Resource Hints as its properties. 220 4.1. Resolving Templated Links 222 A URI can be derived from a Templated Link by treating the "href- 223 template" value as a Level 3 URI Template [RFC6570], using the "href- 224 vars" property to fill the template. 226 The "href-vars" property, in turn, is an object that acts as a 227 mapping between variable names available to the template and absolute 228 URIs that are used as global identifiers for the semantics and syntax 229 of those variables. 231 For example, given the following Resource Object: 233 "http://example.org/rel/widget": { 234 "href-template": "/widgets/{widget_id}", 235 "href-vars": { 236 "widget_id": "http://example.org/param/widget" 237 }, 238 "hints": { 239 "allow": ["GET", "PUT", "DELETE", "PATCH"], 240 "representations": ["application/json"], 241 "accept-patch": ["application/json-patch"], 242 "accept-post": ["application/xml"], 243 "accept-ranges": ["bytes"] 244 } 245 } 247 If you understand that "http://example.org/param/widget" is an 248 numeric identifier for a widget (perhaps by dereferencing that URL 249 and reading the documentation), you can then find the resource 250 corresponding to widget number 12345 at 251 "http://example.org/widgets/12345" (assuming that the Home Document 252 is located at "http://example.org/"). 254 5. Resource Hints 256 Resource hints allow clients to find relevant information about 257 interacting with a resource beforehand, as a means of optimising 258 communications, as well as advertising available behaviours (e.g., to 259 aid in laying out a user interface for consuming the API). 261 Hints are just that - they are not a "contract", and are to only be 262 taken as advisory. The runtime behaviour of the resource always 263 overrides hinted information. 265 For example, a resource might hint that the PUT method is allowed on 266 all "widget" resources. This means that generally, the user has the 267 ability to PUT to a particular resource, but a specific resource 268 could reject a PUT based upon access control or other considerations. 269 More fine-grained information might be gathered by interacting with 270 the resource (e.g., via a GET), or by another resource "containing" 271 it (such as a "widgets" collection). 273 This specification defines a set of common hints, based upon 274 information that's discoverable by directly interacting with 275 resources. A future draft will explain how to define new hints. 277 5.1. allow 279 Hints the HTTP methods that the current client will be able to use to 280 interact with the resource; equivalent to the Allow HTTP response 281 header. 283 Content MUST be an array of strings, containing HTTP methods. 285 5.2. representations 287 Hints the representation types that the resource produces and 288 consumes, using the GET and PUT methods respectively, subject to the 289 'allow' hint. 291 Content MUST be an array of strings, containing media types. 293 5.3. accept-patch 295 Hints the PATCH request formats [RFC5789] accepted by the resource 296 for this client; equivalent to the Accept-Patch HTTP response header. 298 Content MUST be an array of strings, containing media types. 300 When this hint is present, "PATCH" SHOULD be listed in the "allow" 301 hint. 303 5.4. accept-post 305 Hints the POST request formats accepted by the resource for this 306 client. 308 Content MUST be an array of strings, containing media types. 310 When this hint is present, "POST" SHOULD be listed in the "allow" 311 hint. 313 5.5. accept-put 315 Hints the PUT request formats accepted by the resource for this 316 client. 318 Content MUST be an array of strings, containing media types. If 319 absent, a client MAY assume that any format indicated by the 320 'representations' hint is acceptable in a PUT. 322 When this hint is present, "PUT" SHOULD be listed in the "allow" 323 hint. 325 5.6. accept-ranges 327 Hints the range-specifiers available to the client for this resource; 328 equivalent to the Accept-Ranges HTTP response header 329 [I-D.ietf-httpbis-p5-range]. 331 Content MUST be an array of strings, containing HTTP range- 332 specifiers. 334 5.7. prefer 336 Hints the preferences [I-D.snell-http-prefer] supported by the 337 resource. Note that, as per that specifications, a preference can be 338 ignored by the server. 340 Content MUST be an array of strings, contain preferences. 342 5.8. docs 344 Hints the location for human-readable documentation for the relation 345 type of the resource. 347 Content MUST be a string containing an absolute-URI [RFC3986] 348 referring to documentation that SHOULD be in HTML format. 350 5.9. precondition-req 352 Hints that the resource requires state-changing requests (e.g., PUT, 353 PATCH) to include a precondition, as per 354 [I-D.ietf-httpbis-p4-conditional], to avoid conflicts due to 355 concurrent updates. 357 Content MUST be an array of strings, with possible values "etag" and 358 "last-modified" indicating type of precondition expected. 360 5.10. auth-req 362 Hints that the resource requires authentication using the HTTP 363 Authentication Framework [I-D.ietf-httpbis-p7-auth]. 365 Content MUST be an array of objects, each with a "scheme" property 366 containing a string that corresponds to a HTTP authentication scheme, 367 and optionally a "realms" property containing an array of zero to 368 many strings that identify protection spaces that the resource is a 369 member of. 371 For example, a Resource Object might contain the following hint: 373 { 374 "auth-req": [ 375 { 376 "scheme": "Basic", 377 "realms": ["private"] 378 } 379 ] 380 } 382 5.11. status 384 Hints the status of the resource. 386 Content MUST be a string; possible values are: 388 o "deprecated" - indicates that use of the resource is not 389 recommended, but it is still available. 390 o "gone" - indicates that the resource is no longer available; i.e., 391 it will return a 410 Gone HTTP status code if accessed. 393 6. Creating and Serving Home Documents 395 When making a home document available, there are a few things to keep 396 in mind: 398 o A home document is best located at a memorable URI, because its 399 URI will effectively become the URI for the API itself to clients. 400 o Home documents can be personalised, just as "normal" home pages 401 can. For example, you might advertise different URIs, and/or 402 different kinds of link relations, depending on the client's 403 identity. 404 o Home documents SHOULD be assigned a freshness lifetime (e.g., 405 "Cache-Control: max-age=3600") so that clients can cache them, to 406 avoid having to fetch it every time the client interacts with the 407 service. 408 o Custom link relation types, as well as the URIs for variables, 409 should lead to documentation for those constructs. 411 6.1. Managing Change in Home Documents 413 The URIs used in home documents MAY change over time. However, 414 changing them can cause issues for clients that are relying on cached 415 home documents containing old links. 417 To mitigate these risks, servers changing links SHOULD consider: 419 o Reducing the freshness lifetime of home documents before a link 420 change, so that clients are less likely to refer to an "old" 421 document 422 o Assure that they handle requests for the "old" URIs appropriately; 423 e.g., with a 404 Not Found, or by redirecting the client to the 424 new URI. 425 o Alternatively, considering the "old" and "new" URIs as equally 426 valid references for an "overlap" period. 428 Generally, servers ought not to change URIs without good cause. 430 6.2. Evolving and Mixing APIs with Home Documents 432 Using home documents affords the opportunity to change the "shape" of 433 the API over time, without breaking old clients. 435 This includes introducing new functions alongside the old ones - by 436 adding new link relation types with corresponding resource objects - 437 as well as adding new template variables, media types, and so on. 439 It's important to realise that a home document can serve more than 440 one "API" at a time; by listing all relevant relation types, it can 441 effectively "mix" different APIs, allowing clients to work with 442 different resources as they see fit. 444 6.3. Documenting APIs that use Home Documents 446 Another use case for "static" API description formats like WSDL and 447 WADL is to generate documentation for the API from them. 449 An API that uses the home document format correctly won't have a need 450 to do so, provided that the link relation types and media types it 451 uses are well-documented already. 453 7. Consuming Home Documents 455 Clients might use home documents in a variety of ways. 457 In the most common case - actually consuming the API - the client 458 will scan the Resources Object for the link relation(s) that it is 459 interested in, and then to interact with the resource(s) referred to. 460 Resource Hints can be used to optimise communication with the client, 461 as well as to inform as to the permissible actions (e.g., whether PUT 462 is likely to be supported). 464 Note that the home document is a "living" document; it does not 465 represent a "contract", but rather is expected to be inspected before 466 each interaction. In particular, links from the home document MUST 467 NOT be assumed to be valid beyond the freshness lifetime of the home 468 document, as per HTTP's caching model [I-D.ietf-httpbis-p6-cache]. 470 As a result, clients SHOULD cache the home document (as per 471 [I-D.ietf-httpbis-p6-cache]), to avoid fetching it before every 472 interaction (which would otherwise be required). 474 Likewise, a client encountering a 404 Not Found on a link SHOULD 475 obtain a fresh copy of the home document, to assure that it is up-to- 476 date. 478 8. Security Considerations 480 TBD 482 Clients need to exercise care when using hints. For example, a naive 483 client might send credentials to a server that uses the auth-req 484 hint, without checking to see if those credentials are appropriate 485 for that server. 487 9. IANA Considerations 489 TBD 491 10. References 493 10.1. Normative References 495 [I-D.ietf-httpbis-p6-cache] 496 Fielding, R., Lafon, Y., Nottingham, M., and J. Reschke, 497 "HTTP/1.1, part 6: Caching", 498 draft-ietf-httpbis-p6-cache-19 (work in progress), 499 March 2012. 501 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 502 Requirement Levels", BCP 14, RFC 2119, March 1997. 504 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 505 Resource Identifier (URI): Generic Syntax", STD 66, 506 RFC 3986, January 2005. 508 [RFC4627] Crockford, D., "The application/json Media Type for 509 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 511 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. 513 [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., 514 and D. Orchard, "URI Template", RFC 6570, March 2012. 516 10.2. Informative References 518 [I-D.ietf-httpbis-p4-conditional] 519 Fielding, R., Lafon, Y., and J. Reschke, "HTTP/1.1, part 520 4: Conditional Requests", 521 draft-ietf-httpbis-p4-conditional-19 (work in progress), 522 March 2012. 524 [I-D.ietf-httpbis-p5-range] 525 Fielding, R., Lafon, Y., and J. Reschke, "HTTP/1.1, part 526 5: Range Requests and Partial Responses", 527 draft-ietf-httpbis-p5-range-19 (work in progress), 528 March 2012. 530 [I-D.ietf-httpbis-p7-auth] 531 Fielding, R., Lafon, Y., and J. Reschke, "HTTP/1.1, part 532 7: Authentication", draft-ietf-httpbis-p7-auth-19 (work in 533 progress), March 2012. 535 [I-D.snell-http-prefer] 536 Snell, J., "Prefer Header for HTTP", 537 draft-snell-http-prefer-12 (work in progress), 538 February 2012. 540 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 541 Registration Procedures", BCP 13, RFC 4288, December 2005. 543 [RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP", 544 RFC 5789, March 2010. 546 URIs 548 [1] 550 [2] 552 [3] 554 Appendix A. Acknowledgements 556 Thanks to Jan Algermissen, Mike Amundsen, Bill Burke, Graham Klyne, 557 Leif Hedstrom, Jeni Tennison and Jorge Williams for their suggestions 558 and feedback. 560 Appendix B. Frequently Asked Questions 562 B.1. Why not Microformats? 564 Browser-centric Web applications use HTML as their representation 565 format of choice. While it is possible to augment HTML for non- 566 browser clients (using techniques like Microformats [3] ), a few 567 issues become evident when doing so: 569 o HTML has a very forgiving syntax. While this is appropriate for 570 browsers (especially considering that there are many million HTML 571 authors in the world), it makes for a less-than-precise language 572 for machines, resulting in both overhead (parsing and 573 transmission) as well as lack of precision. 574 o HTML is presentation-centric, making it tempting to reformat it 575 from time to time, to improve the "look and feel" of a page. 576 However, doing so can cause comparatively brittle non-browser 577 clients to lose their understanding of the content's semantics, 578 unless very careful controls are in place. 580 Because of this, it's most practical to define a separate format, and 581 JSON is easily machine-readable, precise, and has a better chance of 582 being managed for stability. 584 B.2. What about authentication? 586 In HTTP, authentication is discoverable by interacting with the 587 resource (usually, by getting a 401 Unauthorized response status 588 code, along with one or more challenges). While the home document 589 could hint it, this isn't yet done, to avoid possible security 590 complications. 592 B.3. What about 'Faults' (i.e., errors)? 594 In HTTP, errors are conveyed by HTTP status codes. While this 595 specification could (and even may) allow enumeration of possible 596 error conditions, there's a concern that this will encourage 597 applications to define many such "faults", leading to tight coupling 598 between the application and its clients. 600 So, this is an area of possible future development; if any such 601 mechanism appears here, it's likely to be quite restricted. 603 B.4. How Do I find the XML Schema / JSON Schema / etc. for a particular 604 media type? 606 That isn't addressed by home documents. Ultimately, it's up to the 607 media type accepted and generated by resources to define and 608 constrain (or not) their syntax. 610 B.5. How do I express complex query arguments? 612 Complex queries -- i.e., those that exceed the expressive power of 613 Link Templates or would require ambiguous properties of a "resources" 614 object -- aren't intended to be defined by a home document. The 615 appropriate way to do this is with a "form" language, much as HTML 616 defines. 618 Future revisions of this specification may define or accommodate the 619 use of such a form in the home document. 621 Appendix C. Open Issues 623 The following is a list of placeholders for open issues. 625 o Refining and extending representation formats - "application/xml", 626 for example, isn't enough. While a media type for every 627 representation is one answer, something like 'profile' might be 628 good too. 629 o Object for contact details - do we need an object that describes 630 who's running the API, etc? 631 o Defining new hints - guidance is needed on minting new hints. 632 Possibly a registry. 633 o Defining new top-level properties - how new ones are minted, 634 registry, etc. 635 o Defining new Resource Object properties - how new ones are minted, 636 registry, etc. 637 o Hint to indicate a POST to 201 Created pattern 638 o Hint to indicate an "action" POST 639 o Describe the extensibility model 640 o Allow resources to expose their links 642 Author's Address 644 Mark Nottingham 646 Email: mnot@mnot.net 647 URI: http://www.mnot.net/