Ignore:
Timestamp:
10/09/12 08:28:31 (10 years ago)
Author:
fielding@…
Message:

define representation correctly

Location:
draft-ietf-httpbis/latest
Files:
2 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p2-semantics.html

    r1875 r1876  
    449449  }
    450450  @bottom-center {
    451        content: "Expires March 13, 2013";
     451       content: "Expires March 14, 2013";
    452452  }
    453453  @bottom-right {
    … …  
    498498      <meta name="dct.creator" content="Reschke, J. F.">
    499499      <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">
    501501      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    502502      <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.">
    … …  
    529529            </tr>
    530530            <tr>
    531                <td class="left">Expires: March 13, 2013</td>
     531               <td class="left">Expires: March 14, 2013</td>
    532532               <td class="right">greenbytes</td>
    533533            </tr>
    534534            <tr>
    535535               <td class="left"></td>
    536                <td class="right">September 9, 2012</td>
     536               <td class="right">September 10, 2012</td>
    537537            </tr>
    538538         </tbody>
    … …  
    561561         in progress”.
    562562      </p>
    563       <p>This Internet-Draft will expire on March 13, 2013.</p>
     563      <p>This Internet-Draft will expire on March 14, 2013.</p>
    564564      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    565565      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    586586         <li><a href="#rfc.section.2">2.</a>&nbsp;&nbsp;&nbsp;<a href="#resource">Resource</a></li>
    587587         <li><a href="#rfc.section.3">3.</a>&nbsp;&nbsp;&nbsp;<a href="#representation">Representation</a><ul>
    588                <li><a href="#rfc.section.3.1">3.1</a>&nbsp;&nbsp;&nbsp;<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>&nbsp;&nbsp;&nbsp;<a href="#associating.representation.with.resource">Associating a Representation with its Resource</a></li>
    589589               <li><a href="#rfc.section.3.2">3.2</a>&nbsp;&nbsp;&nbsp;<a href="#representation.header.fields">Representation Header Fields</a><ul>
    590590                     <li><a href="#rfc.section.3.2.1">3.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.content-type">Content-Type</a></li>
    … …  
    876876      <div id="rfc.iref.r.1"></div>
    877877      <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<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>&nbsp;<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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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>&nbsp;<a id="associating.representation.with.resource" href="#associating.representation.with.resource">Associating a Representation with its Resource</a></h2>
    896902      <p id="rfc.section.3.1.p.1">It is sometimes necessary to determine an identifier for the resource associated with a representation.</p>
    897903      <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>
    … …  
    12421248      </p>
    12431249      <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 are
     1250         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
    12451251         implemented or allowed.
    12461252      </p>
    … …  
    12621268                  <td class="left">GET</td>
    12631269                  <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>
    12651271               </tr>
    12661272               <tr>
    … …  
    12721278                  <td class="left">POST</td>
    12731279                  <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>
    12751281               </tr>
    12761282               <tr>
    12771283                  <td class="left">PUT</td>
    12781284                  <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>
    12801286               </tr>
    12811287               <tr>
    … …  
    28622868               <tr>
    28632869                  <td class="left">Date</td>
    2864                   <td class="left"><a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section&nbsp;8.2.1</a></td>
     2870                  <td class="left"><a href="#header.date" id="rfc.xref.header.date.2" title="Date">Section&nbsp;8.2.1</a></td>
    28652871               </tr>
    28662872               <tr>
    … …  
    32763282                  <td class="left">yes</td>
    32773283                  <td class="left">yes</td>
    3278                   <td class="left"> <a href="#GET" id="rfc.xref.GET.2" title="GET">Section&nbsp;5.3.1</a>
     3284                  <td class="left"> <a href="#GET" id="rfc.xref.GET.3" title="GET">Section&nbsp;5.3.1</a>
    32793285                  </td>
    32803286               </tr>
    … …  
    32973303                  <td class="left">no</td>
    32983304                  <td class="left">no</td>
    3299                   <td class="left"> <a href="#POST" id="rfc.xref.POST.2" title="POST">Section&nbsp;5.3.3</a>
     3305                  <td class="left"> <a href="#POST" id="rfc.xref.POST.3" title="POST">Section&nbsp;5.3.3</a>
    33003306                  </td>
    33013307               </tr>
    … …  
    33043310                  <td class="left">no</td>
    33053311                  <td class="left">yes</td>
    3306                   <td class="left"> <a href="#PUT" id="rfc.xref.PUT.2" title="PUT">Section&nbsp;5.3.4</a>
     3312                  <td class="left"> <a href="#PUT" id="rfc.xref.PUT.3" title="PUT">Section&nbsp;5.3.4</a>
    33073313                  </td>
    33083314               </tr>
    … …  
    33403346         a zero-length response body. They can require the presence of one or more particular HTTP response header field(s).
    33413347      </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&nbsp;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&nbsp;3.1</a>; by default, it is anonymous).
    33433349      </p>
    33443350      <h3 id="rfc.section.10.2.3"><a href="#rfc.section.10.2.3">10.2.3</a>&nbsp;<a id="status.code.registration" href="#status.code.registration">Registrations</a></h3>
    … …  
    37223728                  <td class="left">http</td>
    37233729                  <td class="left">standard</td>
    3724                   <td class="left"> <a href="#header.date" id="rfc.xref.header.date.2" title="Date">Section&nbsp;8.2.1</a>
     3730                  <td class="left"> <a href="#header.date" id="rfc.xref.header.date.3" title="Date">Section&nbsp;8.2.1</a>
    37253731                  </td>
    37263732               </tr>
    … …  
    42114217      <p id="rfc.section.C.p.1">Introduce Method Registry. (<a href="#method.registry" title="Method Registry">Section&nbsp;10.1</a>)
    42124218      </p>
    4213       <p id="rfc.section.C.p.2">Clarify definition of POST. (<a href="#POST" id="rfc.xref.POST.3" title="POST">Section&nbsp;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&nbsp;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&nbsp;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&nbsp;5.3.4</a>)
    42164222      </p>
    42174223      <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&nbsp;5.3.6</a>)
    … …  
    50935099            </li>
    50945100            <li><a id="rfc.index.D" href="#rfc.index.D"><b>D</b></a><ul>
    5095                   <li>Date header field&nbsp;&nbsp;<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&nbsp;&nbsp;<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>
    50965102                  <li>deflate (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.d.3">9.4</a></li>
    50975103                  <li>DELETE method&nbsp;&nbsp;<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>
    … …  
    51125118            </li>
    51135119            <li><a id="rfc.index.G" href="#rfc.index.G"><b>G</b></a><ul>
    5114                   <li>GET method&nbsp;&nbsp;<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&nbsp;&nbsp;<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>
    51155121                  <li><tt>Grammar</tt>&nbsp;&nbsp;
    51165122                     <ul>
    … …  
    51945200                        <li>Content-Transfer-Encoding&nbsp;&nbsp;<a href="#rfc.iref.h.22">A.5</a>, <a href="#rfc.xref.no.content-transfer-encoding.1">C</a></li>
    51955201                        <li>Content-Type&nbsp;&nbsp;<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&nbsp;&nbsp;<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&nbsp;&nbsp;<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>
    51975203                        <li>Expect&nbsp;&nbsp;<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>
    51985204                        <li>From&nbsp;&nbsp;<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>
    … …  
    52235229                        <li>CONNECT&nbsp;&nbsp;<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>
    52245230                        <li>DELETE&nbsp;&nbsp;<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&nbsp;&nbsp;<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&nbsp;&nbsp;<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>
    52265232                        <li>HEAD&nbsp;&nbsp;<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>
    52275233                        <li>OPTIONS&nbsp;&nbsp;<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&nbsp;&nbsp;<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&nbsp;&nbsp;<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&nbsp;&nbsp;<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&nbsp;&nbsp;<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>
    52305236                        <li>TRACE&nbsp;&nbsp;<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>
    52315237                     </ul>
    … …  
    53135319                  </li>
    53145320                  <li>payload&nbsp;&nbsp;<a href="#rfc.iref.p.1">4</a></li>
    5315                   <li>POST method&nbsp;&nbsp;<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&nbsp;&nbsp;<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&nbsp;&nbsp;<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&nbsp;&nbsp;<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>
    53175323               </ul>
    53185324            </li>
    … …  
    53205326                  <li>Referer header field&nbsp;&nbsp;<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>
    53215327                  <li>representation&nbsp;&nbsp;<a href="#rfc.iref.r.1">3</a></li>
    5322                   <li><em>REST</em>&nbsp;&nbsp;<a href="#rfc.xref.REST.1">5.1</a>, <a href="#REST"><b>13.2</b></a></li>
     5328                  <li><em>REST</em>&nbsp;&nbsp;<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>
    53235329                  <li>Retry-After header field&nbsp;&nbsp;<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>
    53245330                  <li><em>RFC1123</em>&nbsp;&nbsp;<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  
    106106  <!ENTITY deflate-coding             "<xref target='Part1' x:rel='#deflate.coding' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    107107  <!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'/>">
    109108]>
    110109<?rfc toc="yes" ?>
    … …  
    290289<iref item="representation"/>
    291290<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.
    319331</t>
    320332<t>
    … …  
    325337</t>
    326338
    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">
    328340<t>
    329341   It is sometimes necessary to determine an identifier for the resource
    … …  
    42324244   not allowed), and can define how to determine the resource which they
    42334245   carry a representation for (see <xref
    4234    target="identifying.response.associated.with.representation"/>; by default,
     4246   target="associating.representation.with.resource"/>; by default,
    42354247   it is anonymous).
    42364248</t>
Note: See TracChangeset for help on using the changeset viewer.