draft-ietf-atompub-protocol-01.txt   draft-ietf-atompub-protocol-02.txt 
Network Working Group J. Gregorio, Ed. Network Working Group J. Gregorio, Ed.
Internet-Draft BitWorking, Inc Internet-Draft BitWorking, Inc
Expires: January 17, 2005 R. Sayre, Ed. Expires: March 22, 2005 R. Sayre, Ed.
Boswijck Memex Consulting Boswijck Memex Consulting
July 19, 2004 September 21, 2004
The Atom Publishing Protocol The Atom Publishing Protocol
draft-ietf-atompub-protocol-01.txt draft-ietf-atompub-protocol-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with and any of which I become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 17, 2005. This Internet-Draft will expire on March 22, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
This memo presents a protocol for using XML (Extensible Markup This memo presents a protocol for using XML (Extensible Markup
Language) and HTTP (HyperText Transport Protocol) to edit content. Language) and HTTP (HyperText Transport Protocol) to edit content.
The Atom Publishing Protocol is an application-level protocol for The Atom Publishing Protocol is an application-level protocol for
publishing and editing Web resources belonging to periodically publishing and editing Web resources belonging to periodically
updated websites. The protocol at its core is the HTTP transport of updated websites. The protocol at its core is the HTTP transport of
Atom-formatted representations. The Atom format is documented in the Atom-formatted representations. The Atom format is documented in the
Atom Syndication Format (draft-ietf-atompub-format-00.txt). Atom Syndication Format (draft-ietf-atompub-format-02.txt).
Editorial Note Editorial Note
To provide feedback on this Internet-Draft, join the To provide feedback on this Internet-Draft, join the
<http://www.imc.org/atom-syntax/index.html>. <http://www.imc.org/atom-syntax/index.html>.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Notational Conventions . . . . . . . . . . . . . . . . . . 4 1.1 Notational Conventions . . . . . . . . . . . . . . . . . . 4
1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. The Atom Publishing Protocol Model . . . . . . . . . . . . . 4 2. The Atom Publishing Protocol Model . . . . . . . . . . . . . 4
3. Functional Specification . . . . . . . . . . . . . . . . . . 5 3. Functional Specification . . . . . . . . . . . . . . . . . . 5
3.1 PostURI . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1 PostURI . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.1 Locating the PostURI . . . . . . . . . . . . . . . . . 5 3.1.1 Locating the PostURI . . . . . . . . . . . . . . . . . 5
3.1.2 Request . . . . . . . . . . . . . . . . . . . . . . . 5 3.1.2 Request . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.3 Response . . . . . . . . . . . . . . . . . . . . . . . 5 3.1.3 Response . . . . . . . . . . . . . . . . . . . . . . . 5
3.2 EditURI . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2 EditURI . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.1 Locating . . . . . . . . . . . . . . . . . . . . . . . 7 3.2.1 Locating . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.2 Request . . . . . . . . . . . . . . . . . . . . . . . 7 3.2.2 Request . . . . . . . . . . . . . . . . . . . . . . . 7
3.3 FeedURI . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3 FeedURI . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3.1 Locating . . . . . . . . . . . . . . . . . . . . . . . 9 3.3.1 Locating . . . . . . . . . . . . . . . . . . . . . . . 10
3.3.2 Request . . . . . . . . . . . . . . . . . . . . . . . 9 3.3.2 Request . . . . . . . . . . . . . . . . . . . . . . . 10
3.3.3 Response . . . . . . . . . . . . . . . . . . . . . . . 9 3.3.3 Response . . . . . . . . . . . . . . . . . . . . . . . 10
3.4 Link Tag . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.4 ResourcePostURI . . . . . . . . . . . . . . . . . . . . . 10
3.4.1 rel . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.4.1 Locating . . . . . . . . . . . . . . . . . . . . . . . 10
3.4.2 href . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.4.2 Request . . . . . . . . . . . . . . . . . . . . . . . 11
3.4.3 title . . . . . . . . . . . . . . . . . . . . . . . . 10 3.4.3 Response . . . . . . . . . . . . . . . . . . . . . . . 11
3.4.4 type . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.5 Link Tag . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.5 Atom Request and Response Body Constraints . . . . . . . . 11 3.5.1 rel . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.5.1 id . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.5.2 href . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.5.2 link . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.5.3 title . . . . . . . . . . . . . . . . . . . . . . . . 13
3.5.3 title . . . . . . . . . . . . . . . . . . . . . . . . 11 3.5.4 type . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.5.4 summary . . . . . . . . . . . . . . . . . . . . . . . 11 3.6 Atom Request and Response Body Constraints . . . . . . . . 13
3.5.5 content . . . . . . . . . . . . . . . . . . . . . . . 12 3.6.1 id . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.5.6 issued . . . . . . . . . . . . . . . . . . . . . . . . 12 3.6.2 link . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.5.7 modified . . . . . . . . . . . . . . . . . . . . . . . 12 3.6.3 title . . . . . . . . . . . . . . . . . . . . . . . . 13
3.5.8 created . . . . . . . . . . . . . . . . . . . . . . . 12 3.6.4 summary . . . . . . . . . . . . . . . . . . . . . . . 14
3.5.9 author . . . . . . . . . . . . . . . . . . . . . . . . 13 3.6.5 content . . . . . . . . . . . . . . . . . . . . . . . 14
3.5.10 contributor . . . . . . . . . . . . . . . . . . . . 13 3.6.6 issued . . . . . . . . . . . . . . . . . . . . . . . . 14
3.5.11 generator . . . . . . . . . . . . . . . . . . . . . 13 3.6.7 modified . . . . . . . . . . . . . . . . . . . . . . . 15
3.6 Securing the Atom Protocol . . . . . . . . . . . . . . . . 13 3.6.8 created . . . . . . . . . . . . . . . . . . . . . . . 15
3.6.1 [@@TBD@@ CGI Authentication] . . . . . . . . . . . . . 14 3.6.9 author . . . . . . . . . . . . . . . . . . . . . . . . 15
4. Security Considerations . . . . . . . . . . . . . . . . . . 14 3.6.10 contributor . . . . . . . . . . . . . . . . . . . . 15
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14 3.6.11 generator . . . . . . . . . . . . . . . . . . . . . 15
6. Appendix A - SOAP Enabling . . . . . . . . . . . . . . . . . 15 3.7 Securing the Atom Protocol . . . . . . . . . . . . . . . . 16
6.1 Servers . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.7.1 [@@TBD@@ CGI Authentication] . . . . . . . . . . . . . 16
6.2 Clients . . . . . . . . . . . . . . . . . . . . . . . . . 15 4. Security Considerations . . . . . . . . . . . . . . . . . . 16
7. Appendix B - Examples . . . . . . . . . . . . . . . . . . . 15 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 17
7.1 Example for a weblog . . . . . . . . . . . . . . . . . . . 15 6. Appendix A - SOAP Enabling . . . . . . . . . . . . . . . . . 17
7.2 Example for a wiki . . . . . . . . . . . . . . . . . . . . 15 6.1 Servers . . . . . . . . . . . . . . . . . . . . . . . . . 17
8. Revision History . . . . . . . . . . . . . . . . . . . . . . 15 6.2 Clients . . . . . . . . . . . . . . . . . . . . . . . . . 17
9. Normative References . . . . . . . . . . . . . . . . . . . . 17 7. Appendix B - Examples . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17 7.1 Example for a weblog . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . 19 7.2 Example for a wiki . . . . . . . . . . . . . . . . . . . . 18
8. Revision History . . . . . . . . . . . . . . . . . . . . . . 18
9. Normative References . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . 21
1. Introduction 1. Introduction
The Atom Publishing Protocol is an application-level protocol for The Atom Publishing Protocol is an application-level protocol for
publishing and editing Web resources using HTTP [RFC2616] and XML. publishing and editing Web resources using HTTP [RFC2616] and XML.
1.1 Notational Conventions 1.1 Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
skipping to change at page 4, line 41 skipping to change at page 4, line 41
The Atom Publishing Protocol is an application-level protocol for The Atom Publishing Protocol is an application-level protocol for
publishing and editing Web resources. Using the common HTTP verbs publishing and editing Web resources. Using the common HTTP verbs
provides a pattern for working with all such Web resources: provides a pattern for working with all such Web resources:
o GET is used to retrieve a representation of a resource or perform o GET is used to retrieve a representation of a resource or perform
a read-only query. a read-only query.
o PUT is used to update a known resource. o PUT is used to update a known resource.
o POST is used to create a new dynamically-named resource. o POST is used to create a new dynamically-named resource.
o DELETE is used to remove a resource. o DELETE is used to remove a resource.
There are three major classes of URIs in this specification: PostURI, There are four major classes of URI [RFC2396] in this specification:
FeedURI and EditURI. This specification defines the expected actions PostURI, ResourcePostURI, FeedURI, and EditURI. This specification
for each of the methods listed. A URI MAY support methods not listed defines the expected actions for each of the methods listed. A URI
here. For example, an EditURI could support a POST or OPTIONS MAY support methods not listed here. For example, an EditURI could
method. However, what those methods do is beyond the scope of this support a POST or OPTIONS method. However, what those methods do is
specification. beyond the scope of this specification.
o EditURI: PUT, GET, DELETE o EditURI: PUT, GET, DELETE
o PostURI: POST o PostURI: POST
o FeedURI: GET o FeedURI: GET
o ResourcePostURI: POST
This document does not specify the form of the URIs that are used. This document does not specify the form of the URIs that are used.
The URI space of each server is controlled, as defined by HTTP, by The URI space of each server is controlled, as defined by HTTP, by
the server alone. What this document does specify are the formats of the server alone. What this document does specify are the formats of
the files that are exchanged and the actions that can be performed on the files that are exchanged and the actions that can be performed on
the URIs embedded in those files. the URIs embedded in those files.
3. Functional Specification 3. Functional Specification
3.1 PostURI 3.1 PostURI
The PostURI is used to create entries. These can be either full The PostURI is used to create entries. These can be either full
skipping to change at page 5, line 37 skipping to change at page 5, line 39
The second place a PostURI may be found an atom:link element that is The second place a PostURI may be found an atom:link element that is
a child of the atom:feed element. The third place a PostURI may be a child of the atom:feed element. The third place a PostURI may be
found is in the atom:link element of an atom:entry. found is in the atom:link element of an atom:entry.
@@ TBD @@ - Discuss subordinate resources and what a PostURI means @@ TBD @@ - Discuss subordinate resources and what a PostURI means
based on where the URI was found. based on where the URI was found.
<link rel="service.post" <link rel="service.post"
type="application/atom+xml" type="application/atom+xml"
href="URI for Posting goes here" href="URI for Posting goes here"
title="The name of the site."> title="The name of the site." />
3.1.2 Request 3.1.2 Request
The request contains a filled-in Atom entry, subject to the The request contains a filled-in Atom entry, subject to the
constraints in section Section 3.5. constraints in section Section 3.6.
3.1.3 Response 3.1.3 Response
The possible status codes from a POST are 201, 303, 400, 404, 410 and The possible status codes from a POST are 201, 303, 400, 404, 409,
500. 410 and 500.
3.1.3.1 Response code 201 3.1.3.1 Response code 201
Response includes a Location: header with the URI of the created The Response MUST include a Location: header with the URI of the
resource, i.e. the URI used to edit the entry, as opposed to the URI created resource. The URI returned must be the EditURI of the entry
used to display the content. The body of the response will contain just created. The body of the response SHOULD contain the newly
the entry "filled-in" with time stamps and any other data the server created entry. If the entry is present in the response body then it
chooses to reveal. This must contain enough information to enable a MUST conform to the same constraints listed for responses to a GET on
client to issue a subsequent PUT to this location. Note that the an EditURI. User agents MUST NOT depend on the server returning a
server may chose to omit the content in the response, particularly if response body. If the server does return a response body then the
it is large. user agents MUST NOT depend on the response body having a
content-type of 'application/atom+xml". Note that the server may
choose to omit the content in the response, particularly if it is
large.
A 201 response MAY contain an ETag response header field indicating
the current value of the entity tag for the requested variant just
created.
If the entry returned is subsequently changed the user agent can
update the entry by submitting it via PUT to the EditURI. If an ETag
was returned with the creation of the entry then the user agent
SHOULD include an If-Match: header in the request that contains that
ETag.
3.1.3.2 Response code 303 3.1.3.2 Response code 303
The body of this response does not contain the filled-in Entry, but The body of this response does not contain the filled-in Entry, but
the filled-in Entry can be found under a different URI and can be the filled-in Entry can be found under a different URI and can be
retrieved using a GET method on that resource. The URI SHOULD be retrieved using a GET method on that resource. The URI SHOULD be
given by the Location field in the response. given by the Location field in the response.
3.1.3.3 Response code 400 3.1.3.3 Response code 400
Indicates that the server believes that the data sent constitutes an Indicates that the server believes that the data sent constitutes an
invalid request. As an example, the data posted may not be invalid request. As an example, the data posted may not be
well-formed XML. The server SHOULD include an entity containing an well-formed XML. The server SHOULD include an entity containing an
explanation of the error situation, and whether it is a temporary or explanation of the error situation, and whether it is a temporary or
permanent condition. permanent condition.
3.1.3.4 Response code 500 3.1.3.4 Response code 409
The request contained a valid Atom Entry, but it conflicts with state
on the server. The response SHOULD contain enough for information
for the user to resolve the conflict.
[[@@TBD@@ more about response body format]]
3.1.3.5 Response code 500
Indicates that the server detected an internal error on the server Indicates that the server detected an internal error on the server
processing this request (such as an unhandled exception). The server processing this request (such as an unhandled exception). The server
SHOULD include an entity containing an explanation of the error SHOULD include an entity containing an explanation of the error
situation, and whether it is a temporary or permanent condition. situation, and whether it is a temporary or permanent condition.
3.2 EditURI 3.2 EditURI
An EditURI is used to edit a single entry. Each entry that is An EditURI is used to edit a single entry. Each entry that is
editable MUST have a unique URI. This URI supports both GET and PUT editable MUST have a unique URI. This URI supports both GET and PUT
skipping to change at page 7, line 19 skipping to change at page 7, line 45
For editing a site Entry, the link tag is used. Note that a link tag For editing a site Entry, the link tag is used. Note that a link tag
is used in both HTML and in the Atom format. A link tag of the is used in both HTML and in the Atom format. A link tag of the
following format points to the EditURI for a site. In HTML, the link following format points to the EditURI for a site. In HTML, the link
tags for editing are always found in the head element, while in Atom tags for editing are always found in the head element, while in Atom
they may appear as children of the entry elements. they may appear as children of the entry elements.
<link rel="service.edit" <link rel="service.edit"
type="application/atom+xml" type="application/atom+xml"
href="URI for Editing goes here" href="URI for Editing goes here"
title="Readable desc of the entry."> title="Readable desc of the entry." />
Note: The critical characteristic of this link tag is the @rel of Note: The critical characteristic of this link tag is the @rel of
'service.edit' and the @type of 'application/atom+xml'. 'service.edit' and the @type of 'application/atom+xml'.
3.2.2 Request 3.2.2 Request
A PUT request, and a GET response both contain a filled-in Atom A PUT request, and a GET response both contain a filled-in Atom
entry, subject to the constraints in section Section 3.5. entry, subject to the constraints in section Section 3.6.
The expected status codes from a GET are 200, 301, 307, and 500. The expected status codes from a GET are 200, 301, 307, and 500.
400, 404, and 410 are also possible. 400, 404, and 410 are also possible.
The expected status codes from a PUT are 2xx, 301, 307, 500 and 501. The expected status codes from a PUT are 2xx, 301, 307, 500 and 501.
400, 404, and 410 are also possible. 400, 404, 409, and 410 are also possible.
3.2.2.1 Successful Requests 3.2.2.1 Successful Requests
Servers MUST indicate successful GET requests with a 200 response. Servers MUST indicate successful GET requests with a 200 response.
Servers MUST indicate successful PUT requests with a 2xx response. Servers MUST indicate successful PUT requests with a 2xx response.
Servers MAY include additional information in the PUT response. Servers MAY include additional information in the PUT response.
Clients SHOULD NOT expect any additional information in a PUT Clients SHOULD NOT expect any additional information in a PUT
response. response.
skipping to change at page 8, line 21 skipping to change at page 8, line 45
returned in the Location header. returned in the Location header.
3.2.2.4 Response code 401 3.2.2.4 Response code 401
Indicates that the server believes that the data sent constitutes an Indicates that the server believes that the data sent constitutes an
invalid request. As an example, the data posted may not be invalid request. As an example, the data posted may not be
well-formed XML. The server SHOULD include an entity containing an well-formed XML. The server SHOULD include an entity containing an
explanation of the error situation, and whether it is a temporary or explanation of the error situation, and whether it is a temporary or
permanent condition. permanent condition.
3.2.2.5 Response code 410 3.2.2.5 Response code 409
The request contained a valid Atom Entry, but it conflicts with the
state of the resource, or other state on the server.
For example, a server could signal that the client has erred in this
manner if it receives a request containing an atom:id element whose
value differs from that of the resource found at the requested URI.
The response SHOULD contain enough for information for the user to
resolve the conflict.
[[@@TBD@@ more about response body format ]]
3.2.2.6 Response code 410
Indicates that the requested resource is gone permanently. The Indicates that the requested resource is gone permanently. The
client SHOULD NOT repeat the request again. client SHOULD NOT repeat the request.
3.2.2.6 Response code 500 3.2.2.7 Response code 500
Indicates that the server detected an internal error on the server Indicates that the server detected an internal error on the server
processing this request (such as an unhandled exception). The server processing this request (such as an unhandled exception). The server
SHOULD include an entity containing an explanation of the error SHOULD include an entity containing an explanation of the error
situation, and whether it is a temporary or permanent condition. situation, and whether it is a temporary or permanent condition.
3.3 FeedURI 3.3 FeedURI
The FeedURI is used to retrieve a representation in Atom format. The FeedURI is used to retrieve a representation in Atom format.
Note that this feed is different from a typical Atom feed in that it Note that this feed is different from a typical Atom feed in that it
skipping to change at page 9, line 24 skipping to change at page 10, line 14
multiple link tags with rel="service.feed" and having differing title multiple link tags with rel="service.feed" and having differing title
attributes that announce the kind of search results in that feed. attributes that announce the kind of search results in that feed.
3.3.1 Locating 3.3.1 Locating
A link tag of the following format points to the FeedURI. A link tag of the following format points to the FeedURI.
<link rel="service.feed" <link rel="service.feed"
type="application/atom+xml" type="application/atom+xml"
href="URI goes here" href="URI goes here"
title="The name of the site."> title="The name of the site." />
3.3.2 Request 3.3.2 Request
The request is a simple GET. No other verbs are currently specified The request is a simple GET. No other verbs are currently specified
for this URI. for this URI.
3.3.3 Response 3.3.3 Response
The expected status codes from a GET are 200, 301, 307, and 500. The expected status codes from a GET are 200, 301, 307, and 500.
401, 404, and 410 are also possible. 401, 404, and 410 are also possible.
skipping to change at page 9, line 48 skipping to change at page 10, line 38
The Feed has moved permanently, the new URI is given in the Location The Feed has moved permanently, the new URI is given in the Location
header. The client SHOULD do a GET on the URI returned in the header. The client SHOULD do a GET on the URI returned in the
Location header. Location header.
3.3.3.2 Response code 307 3.3.3.2 Response code 307
The Feed has moved temporarily, the new URI is given in the Location The Feed has moved temporarily, the new URI is given in the Location
header. The client SHOULD do a GET on the URI returned in the header. The client SHOULD do a GET on the URI returned in the
Location header. Location header.
3.4 Link Tag 3.4 ResourcePostURI
The ResourcePostURI is used to create new non-entry resources. The
client POSTs a resource of the desired MIME type directly to this
URI.
3.4.1 Locating
For creating a new non-entry resource, the link tag is used. Note
that a link tag is used in both HTML and in the Atom format. A link
tag of the following format points to the ResourcePostURI for a site.
In HTML the link tags are always found in the head element, while in
Atom they may appear as children of the Feed and entry elements.
<link rel="resource.post" href="URI for Resource Posting goes here"
title="The name of the site.">
3.4.2 Request
The request contains a resource, sent through a standard HTTP POST,
e.g.:
POST /_do/exampleblog/post_resource HTTP/1.1
Host: www.example.com
Content-Type: image/jpeg
Content-Length: nnn
...raw bytes of image go here...
3.4.3 Response
The expected status codes from a POST are 201, 303, 400, 415, and
500. 401, 404, 409, and 410 are also possible.
3.4.3.1 Response code 201
The response MUST include a Location: header with the URI of the
created resource, i.e. the URI used to retrieve the resource
representation in a subsequent HTTP GET. The server SHOULD omit the
content of the resource in the response, since it would be redundant
to return it to the client.
3.4.3.2 Response code 303
Similar to 201 but no caching is allowed. The response MUST include
a Location: header.
3.4.3.3 Response code 400
Indicates that the server believes that the data sent constitutes an
invalid request. The server SHOULD include an entity containing an
explanation of the error situation, and whether it is a temporary or
permanent condition.
3.4.3.4 Response code 415
The MIME type of the request entity is not supported by the server
for this resource.
The response SHOULD contain enough for information for the user to
resolve the conflict.
[[@@TBD@@ more about response body format ]]
3.4.3.5 Response code 500
Indicates that the server detected an internal error on the server
processing this request (such as an unhandled exception). A short
description of the error will appear on the status line itself. A
longer description will appear in the body.
3.5 Link Tag
The link tag is used in both HTML and Atom formats. There are slight The link tag is used in both HTML and Atom formats. There are slight
differences between the two usages. Here are the commonalities, differences between the two usages. Here are the commonalities,
differences, and a list of well-known values for the rel attribute. differences, and a list of well-known values for the rel attribute.
<http://www.w3.org/TR/html4/struct/links.html#edef-LINK> appears in <http://www.w3.org/TR/html4/struct/links.html#edef-LINK> appears in
the 'head' of the document. The 'head' section only allows a linear the 'head' of the document. The 'head' section only allows a linear
list of 'link' tags. The Atom format allows 'link' tags as children list of 'link' tags. The Atom format allows 'link' tags as children
of both the 'feed' element and of the 'entry' element. Note that of both the 'feed' element and of the 'entry' element. Note that
this gives the information present in the link tag more context. For this gives the information present in the link tag more context. For
example ... @@ TBD @@ example ... @@ TBD @@
3.4.1 rel 3.5.1 rel
This attribute describes the relationship from the current document, This attribute describes the relationship from the current document,
be it HTML or Atom, to the anchor specified by the href attribute. be it HTML or Atom, to the anchor specified by the href attribute.
The value of this attribute is a space-separated list of link types. The value of this attribute is a space-separated list of link types.
Note that these values are case insensitive. When used in concert Note that these values are case insensitive. When used in concert
with type="application/atom+xml", the relations may be interpreted as with type="application/atom+xml", the relations may be interpreted as
follows. follows.
alternate: The URI in the href attribute points to an alternate alternate: The URI in the href attribute points to an alternate
representation of the containing resource. representation of the containing resource.
start: The Atom feed at the URI supplied in the href attribute start: The Atom feed at the URI supplied in the href attribute
skipping to change at page 10, line 35 skipping to change at page 12, line 50
contains the next N entries in a linear sequence of entries. contains the next N entries in a linear sequence of entries.
prev: The Atom feed at the URI supplied in the href attribute prev: The Atom feed at the URI supplied in the href attribute
contains the previous N entries in a linear sequence of entries. contains the previous N entries in a linear sequence of entries.
service.edit: The URI given in the href attribute is used to edit a service.edit: The URI given in the href attribute is used to edit a
representation of the referred resource. representation of the referred resource.
service.post: The URI in the href attribute is used to create new service.post: The URI in the href attribute is used to create new
resources. resources.
service.feed: The URI given in the href attribute is a starting point service.feed: The URI given in the href attribute is a starting point
for navigating content and services. for navigating content and services.
3.4.2 href 3.5.2 href
URI of the resource being described by this link element. URI of the resource being described by this link element.
3.4.3 title 3.5.3 title
Offers advisory information about the link. Rendered to the user to Offers advisory information about the link. Rendered to the user to
help them choose among a set of links with the same rel and type help them choose among a set of links with the same rel and type
attributes. attributes.
3.4.4 type 3.5.4 type
The content type of the resource available at the URI given in the The content type of the resource available at the URI given in the
href attribute of the link element. Most of the link types in this href attribute of the link element. Most of the link types in this
specification are on type 'application/atom+xml'. specification are on type 'application/atom+xml'.
3.5 Atom Request and Response Body Constraints 3.6 Atom Request and Response Body Constraints
The Atom format is used as the representation of all the resources in The Atom format is used as the representation of all the resources in
this specification. As it is used in differing contexts, there are this specification. As it is used in differing contexts, there are
different constraints of which elements may be present, and how their different constraints of which elements may be present, and how their
values should be interpreted. values should be interpreted.
3.5.1 id 3.6.1 id
PostURI MUST NOT be present. PostURI MUST NOT be present.
FeedURI MUST be present. FeedURI MUST be present.
EditURI EditURI
GET MUST be present. GET MUST be present.
PUT MUST be present. PUT MUST be present.
3.5.2 link 3.6.2 link
PostURI MAY be present. Servers MAY use the information to determine PostURI MAY be present. Servers MAY use the information to determine
the URI of the created resource. Relative URLs are to be the URI of the created resource. Relative URLs are to be
interpreted relative to xml:base. interpreted relative to xml:base.
FeedURI MUST be present. FeedURI MUST be present.
EditURI EditURI
GET MUST be present. GET MUST be present.
PUT MUST be present. PUT MUST be present.
3.5.3 title 3.6.3 title
PostURI MUST be present. The element may be empty, to explicitly PostURI MUST be present. The element may be empty, to explicitly
indicate "no title". Servers SHOULD NOT try to generate a title indicate "no title". Servers SHOULD NOT try to generate a title
if one is not provided. The type attribute MAY be present, and if if one is not provided. The type attribute MAY be present, and if
not it defaults to "text/plain". If present, it MUST represent a not it defaults to "text/plain". If present, it MUST represent a
MIME type that the server supports. The mode attribute MAY be MIME type that the server supports. The mode attribute MAY be
present. If not present, it defaults to "xml". If present, it present. If not present, it defaults to "xml". If present, it
MUST be "xml", "base64", or "escaped". MUST be "xml", "base64", or "escaped".
FeedURI MUST be present. FeedURI MUST be present.
EditURI EditURI
GET MUST be present. GET MUST be present.
PUT MUST be present. The element may be empty, to explicitly PUT MUST be present. The element may be empty, to explicitly
indicate "no title". Servers SHOULD NOT try to generate a indicate "no title". Servers SHOULD NOT try to generate a
title if one is not provided. title if one is not provided.
3.5.4 summary 3.6.4 summary
PostURI MAY be present. If not present, the server is welcome to PostURI MAY be present. If not present, the server is welcome to
produce its own summary. If present but empty, the server SHOULD produce its own summary. If present but empty, the server SHOULD
NOT generate a summary of its own. The type attribute MAY be NOT generate a summary of its own. The type attribute MAY be
present. If not, it defaults to "text/plain". If present, it present. If not, it defaults to "text/plain". If present, it
must represent a MIME type that the server supports. The mode must represent a MIME type that the server supports. The mode
attribute MAY be present and defaults to "xml". If present, it attribute MAY be present and defaults to "xml". If present, it
must be "xml","base64", or "escaped". must be "xml","base64", or "escaped".
FeedURI MAY be present. FeedURI MAY be present.
EditURI EditURI
GET MAY be present. GET MAY be present.
PUT MAY be present. The element may be empty, to explicitly PUT MAY be present. The element may be empty, to explicitly
indicate "no summary". Servers SHOULD NOT try to generate a indicate "no summary". Servers SHOULD NOT try to generate a
title if one is not provided. title if one is not provided.
3.5.5 content 3.6.5 content
PostURI MAY be present but may be empty, to explicitly indicate "no PostURI MAY be present but may be empty, to explicitly indicate "no
content". The type attribute MAY be present, but defaults to content". The type attribute MAY be present, but defaults to
"text/plain" if not present. It must represent a MIME type that "text/plain" if not present. It must represent a MIME type that
the server supports. The MO