Changeset 1876 for draft-ietf-httpbis/latest
- Timestamp:
- 10/09/12 08:28:31 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r1875 r1876 449 449 } 450 450 @bottom-center { 451 content: "Expires March 1 3, 2013";451 content: "Expires March 14, 2013"; 452 452 } 453 453 @bottom-right { … … 498 498 <meta name="dct.creator" content="Reschke, J. F."> 499 499 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 500 <meta name="dct.issued" scheme="ISO8601" content="2012-09- 09">500 <meta name="dct.issued" scheme="ISO8601" content="2012-09-10"> 501 501 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 502 502 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation."> … … 529 529 </tr> 530 530 <tr> 531 <td class="left">Expires: March 1 3, 2013</td>531 <td class="left">Expires: March 14, 2013</td> 532 532 <td class="right">greenbytes</td> 533 533 </tr> 534 534 <tr> 535 535 <td class="left"></td> 536 <td class="right">September 9, 2012</td>536 <td class="right">September 10, 2012</td> 537 537 </tr> 538 538 </tbody> … … 561 561 in progress”. 562 562 </p> 563 <p>This Internet-Draft will expire on March 1 3, 2013.</p>563 <p>This Internet-Draft will expire on March 14, 2013.</p> 564 564 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 565 565 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 586 586 <li><a href="#rfc.section.2">2.</a> <a href="#resource">Resource</a></li> 587 587 <li><a href="#rfc.section.3">3.</a> <a href="#representation">Representation</a><ul> 588 <li><a href="#rfc.section.3.1">3.1</a> <a href="# identifying.response.associated.with.representation">Identifying the Resource Associated with a Representation</a></li>588 <li><a href="#rfc.section.3.1">3.1</a> <a href="#associating.representation.with.resource">Associating a Representation with its Resource</a></li> 589 589 <li><a href="#rfc.section.3.2">3.2</a> <a href="#representation.header.fields">Representation Header Fields</a><ul> 590 590 <li><a href="#rfc.section.3.2.1">3.2.1</a> <a href="#header.content-type">Content-Type</a></li> … … 876 876 <div id="rfc.iref.r.1"></div> 877 877 <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="representation" href="#representation">Representation</a></h1> 878 <p id="rfc.section.3.p.1">A "<dfn>representation</dfn>" is information in a format that can be readily communicated from one party to another. A resource representation is information 879 that reflects the state of that resource, as observed at some point in the past (e.g., in a response to GET) or to be desired 880 at some point in the future (e.g., in a PUT request). 881 </p> 882 <p id="rfc.section.3.p.2">Most, but not all, representations transferred via HTTP are intended to be a representation of the target resource (the resource 883 identified by the effective request URI). The precise semantics of a representation are determined by the type of message 884 (request or response), the request method, the response status code, and the representation metadata. For example, the above 885 semantic is true for the representation in any <a href="#status.200" class="smpl">200 (OK)</a> response to GET and for the representation in any PUT request. A 200 response to PUT, in contrast, contains either a representation 886 that describes the successful action or a representation of the target resource, with the latter indicated by a <a href="#header.content-location" class="smpl">Content-Location</a> header field with the same value as the effective request URI. Likewise, response messages with an error status code usually 887 contain a representation that describes the error and what next steps are suggested for resolving it. 888 </p> 889 <p id="rfc.section.3.p.3">Request and Response messages <em class="bcp14">MAY</em> transfer a representation if not otherwise restricted by the request method or response status code. A representation consists 890 of metadata (representation header fields) and data (representation body). When a complete or partial representation is enclosed 891 in an HTTP message, it is referred to as the payload of the message. 892 </p> 893 <p id="rfc.section.3.p.4">A representation body is only present in a message when a message body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>. The representation body is obtained from the message body by decoding any <a href="p1-messaging.html#header.transfer-encoding" class="smpl">Transfer-Encoding</a> that might have been applied to ensure safe and proper transfer of the message. 894 </p> 895 <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a> <a id="identifying.response.associated.with.representation" href="#identifying.response.associated.with.representation">Identifying the Resource Associated with a Representation</a></h2> 878 <p id="rfc.section.3.p.1">If we consider that a resource could be anything, and that the uniform interface provided by HTTP is similar to a window through 879 which one can observe and act upon such a thing only through the communication of messages to some independent actor on the 880 other side, then we need an abstraction to represent ("take the place of") the current or desired state of that thing in our 881 communications. We call that abstraction a "<dfn>representation</dfn>" <a href="#REST" id="rfc.xref.REST.1"><cite title="Architectural Styles and the Design of Network-based Software Architectures">[REST]</cite></a>. 882 </p> 883 <p id="rfc.section.3.p.2">For the purposes of HTTP, a <dfn>representation</dfn> is information that reflects the current or desired state of a given resource, in a format that can be readily communicated 884 via the protocol, consisting of a set of metadata (representation header fields) and a potentially unbounded stream of data 885 (representation body). 886 </p> 887 <p id="rfc.section.3.p.3">HTTP messages can transfer a full or partial representation in the payload (<a href="#payload" title="Payload">Section 4</a>) if not otherwise restricted by the request method or response status code. In a request, the purpose of such a representation 888 is defined by the method semantics. In a response, the purpose is defined by both the request method and the response status 889 code. 890 </p> 891 <p id="rfc.section.3.p.4">For example, a representation in the payload of a PUT request (<a href="#PUT" id="rfc.xref.PUT.1" title="PUT">Section 5.3.4</a>) represents the desired state of the target resource if the request is successfully applied, whereas a representation in 892 the payload of a POST request (<a href="#POST" id="rfc.xref.POST.1" title="POST">Section 5.3.3</a>) represents an anonymous resource for providing data to be processed, such as a specific encoding format for the information 893 that a user entered within an HTML form. 894 </p> 895 <p id="rfc.section.3.p.5">Likewise, the payload of a <a href="#status.200" class="smpl">200 (OK)</a> response to GET (<a href="#GET" id="rfc.xref.GET.1" title="GET">Section 5.3.1</a>) contains a representation of the target resource, as observed at the time of the message origination date (<a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section 8.2.1</a>), whereas the same response to POST might contain either a representation of the processing result or a current representation 896 of the target resource after applying the processing. Response messages with an error status code usually contain a representation 897 that describes the error and what next steps are suggested for resolving it. 898 </p> 899 <p id="rfc.section.3.p.6">A representation body is only present in a message when a message body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>. The representation body is obtained from the message body by decoding any <a href="p1-messaging.html#header.transfer-encoding" class="smpl">Transfer-Encoding</a> that might have been applied to ensure safe and proper transfer of the message. 900 </p> 901 <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a> <a id="associating.representation.with.resource" href="#associating.representation.with.resource">Associating a Representation with its Resource</a></h2> 896 902 <p id="rfc.section.3.1.p.1">It is sometimes necessary to determine an identifier for the resource associated with a representation.</p> 897 903 <p id="rfc.section.3.1.p.2">An HTTP request representation, when present, is always associated with an anonymous (i.e., unidentified) resource.</p> … … 1242 1248 </p> 1243 1249 <p id="rfc.section.5.1.p.4">Unlike distributed objects, the standardized request methods in HTTP are not resource-specific, since uniform interfaces provide 1244 for better visibility and reuse in network-based systems <a href="#REST" id="rfc.xref.REST. 1"><cite title="Architectural Styles and the Design of Network-based Software Architectures">[REST]</cite></a>. Once defined, a standardized method <em class="bcp14">MUST</em> have the same semantics when applied to any resource, though each resource determines for itself whether those semantics are1250 for better visibility and reuse in network-based systems <a href="#REST" id="rfc.xref.REST.2"><cite title="Architectural Styles and the Design of Network-based Software Architectures">[REST]</cite></a>. Once defined, a standardized method <em class="bcp14">MUST</em> have the same semantics when applied to any resource, though each resource determines for itself whether those semantics are 1245 1251 implemented or allowed. 1246 1252 </p> … … 1262 1268 <td class="left">GET</td> 1263 1269 <td class="left">Transfer a current representation of the target resource.</td> 1264 <td class="left"><a href="#GET" id="rfc.xref.GET. 1" title="GET">5.3.1</a></td>1270 <td class="left"><a href="#GET" id="rfc.xref.GET.2" title="GET">5.3.1</a></td> 1265 1271 </tr> 1266 1272 <tr> … … 1272 1278 <td class="left">POST</td> 1273 1279 <td class="left">Perform resource-specific processing on the request payload.</td> 1274 <td class="left"><a href="#POST" id="rfc.xref.POST. 1" title="POST">5.3.3</a></td>1280 <td class="left"><a href="#POST" id="rfc.xref.POST.2" title="POST">5.3.3</a></td> 1275 1281 </tr> 1276 1282 <tr> 1277 1283 <td class="left">PUT</td> 1278 1284 <td class="left">Replace all current representations of the target resource with the request payload.</td> 1279 <td class="left"><a href="#PUT" id="rfc.xref.PUT. 1" title="PUT">5.3.4</a></td>1285 <td class="left"><a href="#PUT" id="rfc.xref.PUT.2" title="PUT">5.3.4</a></td> 1280 1286 </tr> 1281 1287 <tr> … … 2862 2868 <tr> 2863 2869 <td class="left">Date</td> 2864 <td class="left"><a href="#header.date" id="rfc.xref.header.date. 1" title="Date">Section 8.2.1</a></td>2870 <td class="left"><a href="#header.date" id="rfc.xref.header.date.2" title="Date">Section 8.2.1</a></td> 2865 2871 </tr> 2866 2872 <tr> … … 3276 3282 <td class="left">yes</td> 3277 3283 <td class="left">yes</td> 3278 <td class="left"> <a href="#GET" id="rfc.xref.GET. 2" title="GET">Section 5.3.1</a>3284 <td class="left"> <a href="#GET" id="rfc.xref.GET.3" title="GET">Section 5.3.1</a> 3279 3285 </td> 3280 3286 </tr> … … 3297 3303 <td class="left">no</td> 3298 3304 <td class="left">no</td> 3299 <td class="left"> <a href="#POST" id="rfc.xref.POST. 2" title="POST">Section 5.3.3</a>3305 <td class="left"> <a href="#POST" id="rfc.xref.POST.3" title="POST">Section 5.3.3</a> 3300 3306 </td> 3301 3307 </tr> … … 3304 3310 <td class="left">no</td> 3305 3311 <td class="left">yes</td> 3306 <td class="left"> <a href="#PUT" id="rfc.xref.PUT. 2" title="PUT">Section 5.3.4</a>3312 <td class="left"> <a href="#PUT" id="rfc.xref.PUT.3" title="PUT">Section 5.3.4</a> 3307 3313 </td> 3308 3314 </tr> … … 3340 3346 a zero-length response body. They can require the presence of one or more particular HTTP response header field(s). 3341 3347 </p> 3342 <p id="rfc.section.10.2.2.p.5">Likewise, their definitions can specify that caches are allowed to use heuristics to determine their freshness (see <a href="#Part6" id="rfc.xref.Part6.17"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>; by default, it is not allowed), and can define how to determine the resource which they carry a representation for (see <a href="# identifying.response.associated.with.representation" title="Identifying the Resource Associated with a Representation">Section 3.1</a>; by default, it is anonymous).3348 <p id="rfc.section.10.2.2.p.5">Likewise, their definitions can specify that caches are allowed to use heuristics to determine their freshness (see <a href="#Part6" id="rfc.xref.Part6.17"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>; by default, it is not allowed), and can define how to determine the resource which they carry a representation for (see <a href="#associating.representation.with.resource" title="Associating a Representation with its Resource">Section 3.1</a>; by default, it is anonymous). 3343 3349 </p> 3344 3350 <h3 id="rfc.section.10.2.3"><a href="#rfc.section.10.2.3">10.2.3</a> <a id="status.code.registration" href="#status.code.registration">Registrations</a></h3> … … 3722 3728 <td class="left">http</td> 3723 3729 <td class="left">standard</td> 3724 <td class="left"> <a href="#header.date" id="rfc.xref.header.date. 2" title="Date">Section 8.2.1</a>3730 <td class="left"> <a href="#header.date" id="rfc.xref.header.date.3" title="Date">Section 8.2.1</a> 3725 3731 </td> 3726 3732 </tr> … … 4211 4217 <p id="rfc.section.C.p.1">Introduce Method Registry. (<a href="#method.registry" title="Method Registry">Section 10.1</a>) 4212 4218 </p> 4213 <p id="rfc.section.C.p.2">Clarify definition of POST. (<a href="#POST" id="rfc.xref.POST. 3" title="POST">Section 5.3.3</a>)4214 </p> 4215 <p id="rfc.section.C.p.3">Remove requirement to handle all Content-* header fields; ban use of <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> with PUT. (<a href="#PUT" id="rfc.xref.PUT. 3" title="PUT">Section 5.3.4</a>)4219 <p id="rfc.section.C.p.2">Clarify definition of POST. (<a href="#POST" id="rfc.xref.POST.4" title="POST">Section 5.3.3</a>) 4220 </p> 4221 <p id="rfc.section.C.p.3">Remove requirement to handle all Content-* header fields; ban use of <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> with PUT. (<a href="#PUT" id="rfc.xref.PUT.4" title="PUT">Section 5.3.4</a>) 4216 4222 </p> 4217 4223 <p id="rfc.section.C.p.4">Take over definition of CONNECT method from <a href="#RFC2817" id="rfc.xref.RFC2817.2"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#CONNECT" id="rfc.xref.CONNECT.3" title="CONNECT">Section 5.3.6</a>) … … 5093 5099 </li> 5094 5100 <li><a id="rfc.index.D" href="#rfc.index.D"><b>D</b></a><ul> 5095 <li>Date header field <a href="#rfc.xref.header.date.1"> 8.2</a>, <a href="#rfc.iref.d.2"><b>8.2.1</b></a>, <a href="#rfc.xref.header.date.2">10.3.2</a></li>5101 <li>Date header field <a href="#rfc.xref.header.date.1">3</a>, <a href="#rfc.xref.header.date.2">8.2</a>, <a href="#rfc.iref.d.2"><b>8.2.1</b></a>, <a href="#rfc.xref.header.date.3">10.3.2</a></li> 5096 5102 <li>deflate (Coding Format) <a href="#rfc.iref.d.3">9.4</a></li> 5097 5103 <li>DELETE method <a href="#rfc.xref.DELETE.1">5.1</a>, <a href="#rfc.iref.d.1"><b>5.3.5</b></a>, <a href="#rfc.xref.DELETE.2">10.1.3</a></li> … … 5112 5118 </li> 5113 5119 <li><a id="rfc.index.G" href="#rfc.index.G"><b>G</b></a><ul> 5114 <li>GET method <a href="#rfc.xref.GET.1"> 5.1</a>, <a href="#rfc.iref.g.6"><b>5.3.1</b></a>, <a href="#rfc.xref.GET.2">10.1.3</a></li>5120 <li>GET method <a href="#rfc.xref.GET.1">3</a>, <a href="#rfc.xref.GET.2">5.1</a>, <a href="#rfc.iref.g.6"><b>5.3.1</b></a>, <a href="#rfc.xref.GET.3">10.1.3</a></li> 5115 5121 <li><tt>Grammar</tt> 5116 5122 <ul> … … 5194 5200 <li>Content-Transfer-Encoding <a href="#rfc.iref.h.22">A.5</a>, <a href="#rfc.xref.no.content-transfer-encoding.1">C</a></li> 5195 5201 <li>Content-Type <a href="#rfc.xref.header.content-type.1">3.2</a>, <a href="#rfc.iref.h.1"><b>3.2.1</b></a>, <a href="#rfc.xref.header.content-type.2">7</a>, <a href="#rfc.xref.header.content-type.3">9.5</a>, <a href="#rfc.xref.header.content-type.4">10.3.1</a>, <a href="#rfc.xref.header.content-type.5">10.3.2</a></li> 5196 <li>Date <a href="#rfc.xref.header.date.1"> 8.2</a>, <a href="#rfc.iref.h.17"><b>8.2.1</b></a>, <a href="#rfc.xref.header.date.2">10.3.2</a></li>5202 <li>Date <a href="#rfc.xref.header.date.1">3</a>, <a href="#rfc.xref.header.date.2">8.2</a>, <a href="#rfc.iref.h.17"><b>8.2.1</b></a>, <a href="#rfc.xref.header.date.3">10.3.2</a></li> 5197 5203 <li>Expect <a href="#rfc.xref.header.expect.1">6.1</a>, <a href="#rfc.iref.h.7"><b>6.1.2</b></a>, <a href="#rfc.xref.header.expect.2">7.5.14</a>, <a href="#rfc.xref.header.expect.3">10.3.2</a>, <a href="#rfc.xref.header.expect.4">C</a></li> 5198 5204 <li>From <a href="#rfc.xref.header.from.1">6.5</a>, <a href="#rfc.iref.h.12"><b>6.5.1</b></a>, <a href="#rfc.xref.header.from.2">10.3.2</a></li> … … 5223 5229 <li>CONNECT <a href="#rfc.xref.CONNECT.1">5.1</a>, <a href="#rfc.iref.m.6"><b>5.3.6</b></a>, <a href="#rfc.xref.CONNECT.2">10.1.3</a>, <a href="#rfc.xref.CONNECT.3">C</a></li> 5224 5230 <li>DELETE <a href="#rfc.xref.DELETE.1">5.1</a>, <a href="#rfc.iref.m.5"><b>5.3.5</b></a>, <a href="#rfc.xref.DELETE.2">10.1.3</a></li> 5225 <li>GET <a href="#rfc.xref.GET.1"> 5.1</a>, <a href="#rfc.iref.m.1"><b>5.3.1</b></a>, <a href="#rfc.xref.GET.2">10.1.3</a></li>5231 <li>GET <a href="#rfc.xref.GET.1">3</a>, <a href="#rfc.xref.GET.2">5.1</a>, <a href="#rfc.iref.m.1"><b>5.3.1</b></a>, <a href="#rfc.xref.GET.3">10.1.3</a></li> 5226 5232 <li>HEAD <a href="#rfc.xref.HEAD.1">5.1</a>, <a href="#rfc.iref.m.2"><b>5.3.2</b></a>, <a href="#rfc.xref.HEAD.2">10.1.3</a></li> 5227 5233 <li>OPTIONS <a href="#rfc.xref.OPTIONS.1">5.1</a>, <a href="#rfc.iref.m.7"><b>5.3.7</b></a>, <a href="#rfc.xref.OPTIONS.2">6.1.1</a>, <a href="#rfc.xref.OPTIONS.3">10.1.3</a></li> 5228 <li>POST <a href="#rfc.xref.POST.1"> 5.1</a>, <a href="#rfc.iref.m.3"><b>5.3.3</b></a>, <a href="#rfc.xref.POST.2">10.1.3</a>, <a href="#rfc.xref.POST.3">C</a></li>5229 <li>PUT <a href="#rfc.xref.PUT.1"> 5.1</a>, <a href="#rfc.iref.m.4"><b>5.3.4</b></a>, <a href="#rfc.xref.PUT.2">10.1.3</a>, <a href="#rfc.xref.PUT.3">C</a></li>5234 <li>POST <a href="#rfc.xref.POST.1">3</a>, <a href="#rfc.xref.POST.2">5.1</a>, <a href="#rfc.iref.m.3"><b>5.3.3</b></a>, <a href="#rfc.xref.POST.3">10.1.3</a>, <a href="#rfc.xref.POST.4">C</a></li> 5235 <li>PUT <a href="#rfc.xref.PUT.1">3</a>, <a href="#rfc.xref.PUT.2">5.1</a>, <a href="#rfc.iref.m.4"><b>5.3.4</b></a>, <a href="#rfc.xref.PUT.3">10.1.3</a>, <a href="#rfc.xref.PUT.4">C</a></li> 5230 5236 <li>TRACE <a href="#rfc.xref.TRACE.1">5.1</a>, <a href="#rfc.iref.m.8"><b>5.3.8</b></a>, <a href="#rfc.xref.TRACE.2">6.1.1</a>, <a href="#rfc.xref.TRACE.3">10.1.3</a>, <a href="#rfc.xref.TRACE.4">11.1</a></li> 5231 5237 </ul> … … 5313 5319 </li> 5314 5320 <li>payload <a href="#rfc.iref.p.1">4</a></li> 5315 <li>POST method <a href="#rfc.xref.POST.1"> 5.1</a>, <a href="#rfc.iref.p.2"><b>5.3.3</b></a>, <a href="#rfc.xref.POST.2">10.1.3</a>, <a href="#rfc.xref.POST.3">C</a></li>5316 <li>PUT method <a href="#rfc.xref.PUT.1"> 5.1</a>, <a href="#rfc.iref.p.3"><b>5.3.4</b></a>, <a href="#rfc.xref.PUT.2">10.1.3</a>, <a href="#rfc.xref.PUT.3">C</a></li>5321 <li>POST method <a href="#rfc.xref.POST.1">3</a>, <a href="#rfc.xref.POST.2">5.1</a>, <a href="#rfc.iref.p.2"><b>5.3.3</b></a>, <a href="#rfc.xref.POST.3">10.1.3</a>, <a href="#rfc.xref.POST.4">C</a></li> 5322 <li>PUT method <a href="#rfc.xref.PUT.1">3</a>, <a href="#rfc.xref.PUT.2">5.1</a>, <a href="#rfc.iref.p.3"><b>5.3.4</b></a>, <a href="#rfc.xref.PUT.3">10.1.3</a>, <a href="#rfc.xref.PUT.4">C</a></li> 5317 5323 </ul> 5318 5324 </li> … … 5320 5326 <li>Referer header field <a href="#rfc.xref.header.referer.1">6.5</a>, <a href="#rfc.iref.r.2"><b>6.5.2</b></a>, <a href="#rfc.xref.header.referer.2">10.3.2</a>, <a href="#rfc.xref.header.referer.3">C</a></li> 5321 5327 <li>representation <a href="#rfc.iref.r.1">3</a></li> 5322 <li><em>REST</em> <a href="#rfc.xref.REST.1"> 5.1</a>, <a href="#REST"><b>13.2</b></a></li>5328 <li><em>REST</em> <a href="#rfc.xref.REST.1">3</a>, <a href="#rfc.xref.REST.2">5.1</a>, <a href="#REST"><b>13.2</b></a></li> 5323 5329 <li>Retry-After header field <a href="#rfc.xref.header.retry-after.1">7.6.4</a>, <a href="#rfc.xref.header.retry-after.2">8.1</a>, <a href="#rfc.iref.r.3"><b>8.1.2</b></a>, <a href="#rfc.xref.header.retry-after.3">10.3.2</a></li> 5324 5330 <li><em>RFC1123</em> <a href="#rfc.xref.RFC1123.1">9.1</a>, <a href="#rfc.xref.RFC1123.2">9.1</a>, <a href="#RFC1123"><b>13.2</b></a><ul> -
draft-ietf-httpbis/latest/p2-semantics.xml
r1875 r1876 106 106 <!ENTITY deflate-coding "<xref target='Part1' x:rel='#deflate.coding' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 107 107 <!ENTITY gzip-coding "<xref target='Part1' x:rel='#gzip.coding' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 108 <!ENTITY response-representation "<xref target='identifying.response.associated.with.representation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">109 108 ]> 110 109 <?rfc toc="yes" ?> … … 290 289 <iref item="representation"/> 291 290 <t> 292 A "<x:dfn>representation</x:dfn>" is information in a format that can be readily 293 communicated from one party to another. A resource representation 294 is information that reflects the state of that resource, as observed 295 at some point in the past (e.g., in a response to GET) or to be 296 desired at some point in the future (e.g., in a PUT request). 297 </t> 298 <t> 299 Most, but not all, representations transferred via HTTP are intended 300 to be a representation of the target resource (the resource identified 301 by the effective request URI). The precise semantics of a representation 302 are determined by the type of message (request or response), the request 303 method, the response status code, and the representation metadata. For 304 example, the above semantic is true for the representation in any 305 <x:ref>200 (OK)</x:ref> response to GET and for the representation in any PUT request. 306 A 200 response to PUT, in contrast, contains either a representation 307 that describes the successful action or a representation of the target 308 resource, with the latter indicated by a <x:ref>Content-Location</x:ref> 309 header field with the same value as the effective request URI. Likewise, 310 response messages with an error status code usually contain a representation 311 that describes the error and what next steps are suggested for resolving it. 312 </t> 313 <t> 314 Request and Response messages &MAY; transfer a representation if not otherwise 315 restricted by the request method or response status code. A representation 316 consists of metadata (representation header fields) and data (representation 317 body). When a complete or partial representation is enclosed in an HTTP message, 318 it is referred to as the payload of the message. 291 If we consider that a resource could be anything, and that the uniform 292 interface provided by HTTP is similar to a window through which one 293 can observe and act upon such a thing only through the communication of 294 messages to some independent actor on the other side, then we need an 295 abstraction to represent ("take the place of") the current or desired state 296 of that thing in our communications. We call that abstraction a 297 "<x:dfn>representation</x:dfn>" <xref target="REST"/>. 298 </t> 299 <t> 300 For the purposes of HTTP, a <x:dfn>representation</x:dfn> is information 301 that reflects the current or desired state of a given resource, in a format 302 that can be readily communicated via the protocol, consisting of a set of 303 metadata (representation header fields) and a potentially unbounded stream 304 of data (representation body). 305 </t> 306 <t> 307 HTTP messages can transfer a full or partial representation in the payload 308 (<xref target="payload"/>) if not otherwise restricted by the request 309 method or response status code. In a request, the purpose of such a 310 representation is defined by the method semantics. In a response, the 311 purpose is defined by both the request method and the response status code. 312 </t> 313 <t> 314 For example, a representation in the payload of a PUT request 315 (<xref target="PUT"/>) represents the desired state of the target resource 316 if the request is successfully applied, whereas a representation in the 317 payload of a POST request (<xref target="POST"/>) represents an anonymous 318 resource for providing data to be processed, such as a specific encoding 319 format for the information that a user entered within an HTML form. 320 </t> 321 <t> 322 Likewise, the payload of a <x:ref>200 (OK)</x:ref> response to GET 323 (<xref target="GET"/>) contains a representation of the target resource, 324 as observed at the time of the message origination date 325 (<xref target="header.date"/>), whereas the same response to POST might 326 contain either a representation of the processing result or a current 327 representation of the target resource after applying the processing. 328 Response messages with an error status code usually contain a 329 representation that describes the error and what next steps are suggested 330 for resolving it. 319 331 </t> 320 332 <t> … … 325 337 </t> 326 338 327 <section title=" Identifying the Resource Associated with a Representation" anchor="identifying.response.associated.with.representation">339 <section title="Associating a Representation with its Resource" anchor="associating.representation.with.resource"> 328 340 <t> 329 341 It is sometimes necessary to determine an identifier for the resource … … 4232 4244 not allowed), and can define how to determine the resource which they 4233 4245 carry a representation for (see <xref 4234 target=" identifying.response.associated.with.representation"/>; by default,4246 target="associating.representation.with.resource"/>; by default, 4235 4247 it is anonymous). 4236 4248 </t>
Note: See TracChangeset
for help on using the changeset viewer.