Abstract
Proposes a standardized Ping mechanism for the Atom Protocol
Introduce a new Ping interface. The Ping interface would be represented by a URI that accepts a POST. That POST would include an Atom Entry Document describing the resource that was updated
POST /ping-interface HTTP/1.1
Host: myhost.com
Content-Type: application/atom+xml
Content-Length: nnnn
<?xml ... ?>
<notification action="updated">
<entry xmlns="http://www.w3.org/2005/Atom" xmlns:pub="...">
<id>tag:example.com:1</id>
<link href="http://www.example.com/entries/1" />
<title>My Entry</title>
<updated>2005-07-25T12:00:00Z</updated>
<author>
<name>James Snell</name>
</author>
<summary>This is a blog entry</summary>
</entry>
</notification>
-
The semantics of the Ping POST are simple: It's nothing more than a notification. No persistent resources are created in response to the POST. The receiver is expected simply to either accept the Ping with a 202 Accepted response or reject the ping with some form of 4xx or 5xx response.
Status
Withdrawn. (JamesSnell)
Rationale
-
The Ping notification mechanisms currently employed by services like Technorati and blo.gs currently use different, non-standardized XML-RPC based mechanisms for supporting notifications about site content changes. Trackbacks use yet another mechanism. Other suggestions have been made for things like Pingback, extended pings, etc. The goal of this proposal is to provide a single unified approach for pings and trackbacks that is a) based on and part of the core Atom Protocol spec and b) does not add any significant additional complexity to the Atom Protocol.
Proposal
(rename the existing section "4.5 Success and Failure" to "4.6 Success and Failure".. and insert the following)
4.5 Notification
When a resource has been created, modified or deleted from a collection, the client or server MAY notify a remote endpoint of the action by sending an HTTP request carrying a Notification Document.
Client Server | | | 1.) POST to Notification URI | |------------------------------->| | | | 2.) 202 Accepted, No Content | |<-------------------------------| | |
-
The client sends a Notification Document to the server via HTTP POST. The Request URI is that of the notification endpoint.
-
The server responds with a response of 202 Accepted.
4.5.1 Notification Documents
-
A Notification Document is used to notify a remote endpoint of an action taken on one or more collection members. Each member of the collection affected by the action is represented by an atom:entry contained within the Notification Document.
atomNotification =
element app:notification {
attribute action { "created", "updated", "deleted" },
atom:entry*
}
For example,
POST /notification_uri HTTP/1.1
Host: myhost.com
Content-Type: application/atom+xml
Content-Length: nnnn
<?xml ... ?>
<notification xmlns="..." action="created">
<entry xmlns="http://www.w3.org/2005/Atom">
<id>tag:example.com:1</id>
<link href="http://www.example.com/entries/1" />
<title>My Entry</title>
<updated>2005-07-25T12:00:00Z</updated>
<author>
<name>James Snell</name>
</author>
<summary>This is a blog entry</summary>
</entry>
</notification>
Example response, Notification Accepted
HTTP/1.1 202 Accepted
Date: Fri, 25 Mar 2005 12:00:00 GMT
Content-Length: 0
