| yes | J.C. Gregorio |
| BitWorking, Inc | |
| July 2003 |
The AtomAPI
draft-gregorio-07.html
This memo presents a technique for using XML (Extensible Markup Language) and HTTP (HyperText Transport Protocol) to edit content.
To provide feedback on this draft RFC please visit the Atom Wiki.
1
Introduction
2
Terminology
3
Scope
4
The AtomAPI Model
5
The AtomAPI Procedure
5.1
Introspection
5.1.1
Introspection Discovery
5.2
Creating a new Entry request
5.2.1
Retrieving an Entry
5.3
Editing an entry
5.4
Deleting an entry
5.5
Finding an entry
5.6
Editing User Prefs
5.7
Editing Templates
5.8
Adding Comments
5.8.1
Comment Auto-Discovery
5.8.1.1
HTML Auto-Discovery
5.8.1.2
Atom Feed Auto-Discovery
6
Functional Specification
6.1
Formats
6.2
Actions
6.2.1
Create Entry
6.2.2
Edit Entry
6.2.3
Delete Entry
6.2.4
Get List of Entries
6.2.5
Get User Info
6.2.6
Set User Info
6.2.7
Get Categories
6.2.8
Set Categories
6.2.9
Result Codes
6.2.10
Content
7
Security Considerations
8
Revision History
9
Copyright
§
References
§
Author's Address
§
Intellectual Property and Copyright Statements
AtomAPI is an application level protocol for publishing, and editing web resources. AtomAPI unifies many disparate publishing mechanisms into a single, simple, extensible protocol. The protocol at its core is the HTTP transport of an XML payload.
To provide feedback on this draft RFC please visit the Atom Wiki.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",the and "OPTIONAL" in this document are to be interpreted as described in RFC2119.
This document covers the editing of content of a periodically updating website using the HTTP and XML. Many of the XML payloads are in Atom format, which will not be documented here.
This specification will mirror some of the functionality of the Blogger 2.0 API, which includes support for the Server Introspection API.
AtomAPI is an application level protocol for publishing and editing web resources. Using the common HTTP verbs provides a pattern for working with all such web resources:
There are different kinds of resources managed by the AtomAPI, each of these have URIs and those URIs support a subset of the above actions.
This RFC 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 server alone. What this RFC does specify are the formats of the files that are exchanged and the actions that can be performed on the URIs embedded in those files.
When editing the content of the website http://example.org/reilly, the first thing to do is find out the servers capabilites. Each server may only implement a subset of this specification, and the 'introspection' file lists all the functions that each site supports. This mirrors the Server Introspection API used by the Blogger 2.0 API.
<?xml version="1.0" encoding='iso-8859-1'?> <introspection xmlns="http://example.com/newformat#" > <create-entry>http://example.org/reilly/</create-entry> <user-prefs>http://example.org/reilly/prefs</user-prefs> <search-entries>http://example.org/reilly/search</search-entries> </introspection>
Each element in <introspection> represents a single facet of the AtomAPI. While a site must fully support each facet they list in their introspection file, a site does not need to support all the facets in this RFC. Additionally, new facets may be added either through vendor extension or follow-on RFCs. This first example site furnishes only a minimal set of functionality. A more full featured site might return:
<?xml version="1.0" encoding='iso-8859-1'?> <introspection xmlns="http://example.com/newformat#" > <create-entry>http://example.org/reilly/</create-entry> <user-prefs>http://example.org/reilly/prefs</user-prefs> <search-entries>http://example.org/reilly/search</search-entries> <edit-template>http://example.org/reilly/templates</edit-template> <categories>http://example.org/reilly/categories</categories> </introspection>
This particular introspection file for http://example.org/reilly tells us that the AtomAPI implementation supports both the 'create-entry' and the 'user-prefs' interfaces, and it also specifies the URIs to use for each of these interfaces.
Note that the example URIs given are not normative, nor are there any constraints on the URIs that can be specified. The 'create-entry' URI could just have easily been:
http://dev.example.net/api?userid=reilly&action=create
The <link> element has been successful in finding RSS feeds and is appropriate to use here for discovering the location of the Introspection file. The <link> tag goes in the <head> section of an HTML page and is used to indicate a document relationship. For a similar example of using the link tag to discover a URI, refer to the usage of of the link tag for RSS Auto-Discovery. In this case the form of the link tag used to indicate the location of the comment URI is:
<link rel="service.edit" type="application/x.atom+xml"
href="url goes here" title="AtomAPI">
Where href should be set to the URI of the Introspection file. Applications looking for the Introspection file to need to parse out the headers of the web page and look for a link tag that has a relation rel of "service.edit" and a mime-type of "application/x.atom+xml".
HTTP POST is used for content creation. The new content is formatted as an Atom Entry and then POSTed to the URI given in the <create-entry/> element of the Introspection file.
To create a new Entry on the site the client connects to port 80 on http://example.org and sends:
POST /reilly HTTP/1.1
Content-Type: application/x.atom+xml
<?xml version="1.0" encoding='iso-8859-1'?>
<entry xmlns="http://example.com/newformat#" >
<title>My First Entry</title>
<summary>A very boring entry...</summary>
<author>
<name>Bob B. Bobbington</name>
</author>
<created>2003-02-05T12:29:29</created>
<content type="application/xhtml+xml" xml:lang="en-us">
<p xmlns="...">Hello, <em>weblog</em> world! 2 < 4!</p>
</content>
</entry>
This would create a new weblog Entry with the title "My First Entry". Note that in all the examples the full set of HTTP headers for each request and response are not shown, only the most relevant headers are displayed.
Assuming everything goes well and the Entry is created the response might look like:
HTTP/1.1 201 Created Location: http://example.org/reilly/1
The URI of the filled in Entry is returned via the HTTP headers. The AtomAPI service is responsible for allocating the URI for the Entry. The URI allocation mechanism is implementation dependent and not defined by this document. If a GET is done on the returned URI then a filled in Entry would be returned, including the elements <link/>, <id/>, <created/> and <modified/>.
To retrieve the new Entry on the site the client needs to know the URI of the Atom Entry. This URI is obtained either by the HTTP Location header returned during the creation of the Entry as outlined in section 5.2, or it is discovered by the search interface discussed in section 5.5.
For the newly created Atom Entry above, the client connects to port 80 on http://example.org and sends:
GET /reilly/1 HTTP/1.1 Accept: application/x.atom+xml
This would retrieve the Entry just created.
The response might look like:
HTTP/1.1 200 Ok
Content-Type: application/x.atom+xml
<?xml version="1.0" encoding='iso-8859-1'?>
<entry xmlns="http://example.com/newformat#" >
<title>My First Entry</title>
<summary>A very boring entry...</summary>
<author>
<name>Bob B. Bobbington</name>
</author>
<issued>2003-02-05T12:29:29</issued>
<created>2003-02-05T14:10:58Z</created>
<modified>2003-02-05T14:10:58Z</modified>
<link>http://example.org/reilly/2003/02/05#My_First_Entry</link>
<id>urn:example.org:reilly:1</id>
<content type="application/xhtml+xml" xml:lang="en-us">
<p xmlns="...">Hello, <em>weblog</em> world! 2 < 4!</p>
</content>
</entry>
Information has been added to the Entry, including the <link/>, <id/>, <created/> and <modified/> elements.
@@ Editors Note: Beware the Atom syntax is still in flux and the above example is not normative. @@
Editing an Entry is different from creating one, the difference is that the Entry is PUT back to the URI that you retrieved it from via GET.
If the <content/> element is updated the transaction might look like:
PUT /reilly/1 HTTP/1.1
Content-Type: application/x.atom+xml
<?xml version="1.0" encoding='iso-8859-1'?>
<entry xmlns="http://example.com/newformat#" >
<title>My First Entry</title>
<summary>A very boring entry...</summary>
<author>
<name>Bob B. Bobbington</name>
</author>
<issued>2003-02-05T12:29:29</issued>
<created>2003-02-05T14:10:58Z</created>
<modified>2003-02-05T14:10:58Z</modified>
<link>http://example.org/reilly/2003/02/05#My_First_Entry</link>
<id>urn:example.org:reilly:1</id>
<content type="application/xhtml+xml" xml:lang="en-us">
<p xmlns="...">A big hello to the
<em>weblog</em> world! 2 < 4!</p>
</content>
</entry>
The response from the server, on success, returns a 205 HTTP status code.
HTTP/1.1 205 Reset Content
The <content/> element now reflects the updated content, and the <modifed/> element has been updated to reflect when the change was made.
As was done after creation, a GET to the URI of the Atom Entry would return the modified Entry.
To retrieve the modified Entry the client connects to port 80 on http://example.org and sends:
GET /reilly/1 HTTP/1.1 Content-Type: application/x.atom+xml
This would retrieve the recently modified Entry.
The response might look like:
HTTP/1.1 200 Ok
Content-Type: application/x.atom+xml
<?xml version="1.0" encoding='iso-8859-1'?>
<entry xmlns="http://example.com/newformat#" >
<title>My First Entry</title>
<summary>A very boring entry...</summary>
<author>
<name>Bob B. Bobbington</name>
</author>
<issued>2003-02-05T12:29:29</issued>
<created>2003-02-05T14:10:58Z</created>
<modified>2003-02-05T14:22:03Z</modified>
<link>http://example.org/reilly/2003/02/05#My_First_Entry</link>
<id>urn:example.org:reilly:1</id>
<content type="application/xhtml+xml" xml:lang="en-us">
<p xmlns="...">A big hello to the
<em>weblog</em> world! 2 < 4!</p>
</content>
</entry>
The <content/> element now reflects the updated content, and the <modifed/> element has been updated to reflect when the change was made.
Deleting an Entry uses the URI of the Atom Entry. This is the same URI the client does a GET on to retrieve the Atom Entry.
For example, to delete the first Entry in our example the client connects to port 80 on the server and sends:
DELETE /reilly/1 HTTP/1.1
The response from the server upon a successful deletion is:
HTTP/1.1 200 Ok
Finding an Entry uses the 'search-entries' URI from the Introspection file. For the example Introspection file given, that is the URI http://example.org/reilly/search. The search parameters given are used to select which Entries are listed in the response.
For example, to retrieve the locations of the last 20 Entries, the client connects to port 80 on the server and sends:
GET /reilly/search?atom-last=20 HTTP/1.1 Accept: application/x.atom+xml
The server searches for Entries that match the criteria and returns a response that lists those matches.
The response from the server might look like:
HTTP/1.1 200 Ok
Content-Type: application/x.atom+xml
<search-results xmlns="http://example.com/newformat#" >
<entry>
<title>My First Post</title>
<id>http://example.org/reilly/1</id>
</entry>
<entry>
<title>My Second Post</title>
<id>http://example.org/reilly/2</id>
</entry>
</search-results>
There will be one <entry/> element for every Entry that matches the given criteria. Each <entry/> element contains the URI of the Entry and the title of the Entry. If the client needs the Atom Entry then it performs an HTTP GET on the given URI as outlined in section 5.2.1.
Note that all of the query parameters begin with 'atom-' to avoid conflicts with other query parameters that may already be present in the URI.
There are other search critera that can be added. For example the 'atom-all' parameter, if present, requests that the server return a list of all Entries on the site. Other additional parameters that can be added are 'atom-start-range' and 'atom-end-range'. Access to the entries is by an index, with the first Entry having an index number of 0.
For example, this request will return a list of all Entries from index 2 to index 27.
GET /reilly/search?start-range=2&end-range=27 HTTP/1.1
The rest of the search parameters and their properties are covered in detail in section 6.1.
Note that the URI the client receives for the search facet may already have query parameters in it so the client may not just append the query parameters to the end of the search URI. The best approach to handling this situation is to parse out all the query parameters, add in the ones being used by the client then join the URI back together.
The preferences for the user are edited through the URI supplied in the <user-prefs/> element of the introspection file. To retrieve the current user preferences issue and HTTP GET on the URI.
For the website at http://example.org/reilly, the request would look like:
GET /reilly/prefs HTTP/1.1 Accept: application/x.atom+xml
This would return a list of user configuration parameters and their values.
The reponse would look like:
HTTP/1.1 200 OK Content-Type: application/x.atom+xml <?xml version="1.0" encoding='iso-8859-1'?> <userprefs xmlns="http://example.com/newformat#" > <name>Reilly</name> <id>1234</id> <email>reilly@example.org</email> </userprefs>
The values can then be updated, and doing an HTTP PUT of the updated file back to the 'user-prefs' URI will update the user preferences.
For example, if we update our email address, from reilly@example.org to sputnik@example.org, we would then PUT it back to the 'user-prefs' URI:
PUT /reilly/prefs HTTP/1.1 Content-Type: application/x.atom+xml <?xml version="1.0" encoding='iso-8859-1'?> <userprefs xmlns="http://example.com/newformat#" > <name>Reilly</name> <id>1234</id> <email>sputnik@example.org</email> </userprefs>
Assuming the update goes successfully, the updated user preferences will be returned in the response.
The reponse would look like:
HTTP/1.1 200 OK
The templates for the user are edited through the URI supplied in the <edit-template/> element of the introspection file. Doing an HTTP GET on the edit-template URI retrieves a file that describes all the available templates and their URIs.
Here is an example template description file.
<resources xmlns="http://example.com/newformat#" >
<resource>
<title>Main</title>
<id>http://example.org/tpl/Main.html</id>
</resource>
<resource>
<title>Story</title>
<id>http://example.org/tpl/Stry.html</id>
</resource>
<resource>
<title>Feed</title>
<id>http://example.org/tpl/Feed.xml</id>
</resource>
</resources>
Two important things to note on this file. First is that this list of templates is in no way normative. Secondly, note that templates may have different mime-types.
To begin editing a template, do a GET on one of the listed URIs. After the content has been edited the client PUTs the modified content back to the same URI.
This part of the AtomAPI does not use the URIs listed in the Introspection file.
There are different interfaces now circulating for an TrackBack, Ping-Back, Post-It. All of these are systems for adding comment-like information to an Entry. The only thing missing from the mix is a way to do comments themselves. This section of the specification is intended to be a roll-up of all the above specifications and to cover comments as well.
Creating a comment is similar to creating an Entry, that is, you HTTP POST an Entry to a URI. For now we will defer discussing how to obtain the corrent URI to POST to.
For example, if "http://example.org/reilly/1/comments" is the URI that accepts comments for the first Entry on the website http://example.org/reilly, then the client would open port 80 on example.org and send:
POST /reilly/1/comments HTTP/1.1
Content-Type: application/x.atom+xml
<entry xmlns="http://example.com/newformat#" >
<title>My Comment</title>
<author>
<name>Fred F. Fobbington</name>
</author>
<created>2003-02-05T12:29:29</created>
<content type="application/xhtml+xml" xml:lang="en-us">
<p xmlns="...">Welcome to the neighborhood!</p>
</content>
</entry>
This would create a new comment for the first Entry on "http://example.org/reilly".
The response to this POST, assuming everything went without error would look like this:
HTTP/1.1 201 Created Location: http://example.org/reilly/1/comments/1
This would create a new comment/trackback for the first Entry on "http://example.org/reilly".
Note that the response can contain a Location: header that points to the comment as an Entry. This is not a required feature of the interface.
Two mechanisms are available for discovering the URI that you would use to create a comment. The first is a way to put that information in HTML, the second is a way to embed that information in an Atom feed.
The <link> element has been successful in finding RSS feeds and is appropriate to use here for discovering the "commentURI" in HTML pages. The <link> tag goes in the <head> section of an HTML page and is used to indicate a document relationship. For a similar example of using the link tag to discover a URI, refer to the usage of of the link tag for RSS Auto-Discovery. In this case the form of the link tag used to indicate the location of the comment URI is:
<link rel="service.comment" type="application/x.atom+xml"
href="url goes here" title="AtomComment">
Where href should be set to the URI that accepts POSTs for comments. Applications looking for a URI to post comments to need to parse out the headers of the web page and look for a link tag that has a relation rel of "service.comment" and a mime-type of "application/x.atom+xml".
There is a <comment/> element in each Entry that is used to provide the location of the URI that accepts comment POSTs. This is providing the same information as the link tag does in HTML.
@@ TBD @@ More formal specification of all the XML formats used in this protocol.
@@ TBD @@ A more formal specification of all the actions.
None.
None.
None.
None.
None.
None.
None.
None.
@@TBD@@ Mostly 200 for normal responses, seems that 30X codes for redirects are useful but might make implementations a little harder to implement. @@Ref CommentAPI problems returning a 303 vs 200@@
@@TBD@@ How does an Atom document change when used in these different contexts? Which parts that are required when found in a feed become optional when used in creating an Entry?
@@TBD@@ Talk here about using HTTP basic and digest authentication.
@@TBD@@ Talk here about denial of service attacks using large XML files, or the billion laughs DTD attack.
Rev 07 - 06Aug2003 - Removed the use of the RSD file for auto-discovery. Changed copyright until a final standards body is chosen. Changed query parameters for the search facet to all begin with atom- to avoid name collisions. Updated all the Entries to follow the 0.2 version. Changed the format of the search results and template file to a pure element based syntax.
Rev 06 - 24Jul2003 - Moved to PUT for updating Entries. Changed all the mime-types to application/x.atom+xml. Added template editing. Changed 'edit-entry' to 'create-entry' in the Introspection file to more accurately reflect it's purpose.
Rev 05 - 17Jul2003 - Renamed everything Echo into Atom. Added version numbers in the Revision history. Changed all the mime-types to application/atom+xml.
Rev 04 - 15Jul2003 - Updated the RSD version used from 0.7 to 1.0. Change the method of deleting an Entry from POSTing <delete/> to using the HTTP DELETE verb. Also changed the query interface to GET instead of POST. Moved Introspection Discovery to be up under Introspection. Introduced the term 'facet' for the services listed in the Introspection file.
Rev 03 - 10Jul2003 - Added a link to the Wiki near the front of the document. Added a section on finding an Entry. Retrieving an Entry now broken out into it's own section. Changed the HTTP status code for a successful editing of an Entry to 205.
Rev 02 - 7Jul2003 - Entries are no longer returned from POSTs, instead they are retrieved via GET. Cleaned up figure titles, as they are rendered poorly in HTML. All content-types have been changed to application/atom+xml.
Rev 01 - 5Jul2003 - Renamed from EchoAPI.html to follow the more commonly used format: draft-gregorio-NN.html. Renamed all references to URL to URI. Broke out introspection into it's own section. Added the Revision History section. Added more to the warning that the example URIs are not normative.
Copyright (C) Joe Gregorio (2003). All Rights Reserved.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| Joe Gregorio | |
| BitWorking, Inc | |
| 1002 Heathwood Dairy Rd. |
|
| Apex, NC 27502 | |
| US | |
| Phone: | +1 919 272 3764 |
| EMail: | joe@bitworking.com |
| URI: | http://bitworking.com/ |