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

define representation correctly

File:
1 edited

Legend:

Unmodified
Added
Removed
  • 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.