Ernest Prabhakar in the rest-discuss mailing list:
I would love to see someone define/build a hAtom version of AtomPub, that worked in standard web browsers.
Here’s one way to not make friends or influence people.
Deep breath.
The Simple Publishing Protocol
The Simple Publishing Protocol describes a mechanism for retrieving a collection of entries or individual entries, and for publishing and editing entries, as is commonly present in Blogs, photo and video sharing sites, social networks, and other Web 2.0 wonderkids.
The goals of the Simple Publishing Protocol:
- To provide a uniform mechanism for publishing and consuming collections of rich media,
- Support the Web Browser stack, and
- Do the simplest thing that could possibly work.
Retrieving Entries
The client makes a GET request to a known URL containing an entry or collection of entries, requesting a presentation in any content type suitable to the client.
For the purpose of this discussion, we refer to content types compatible with (X)HTML (text/html, application/xhtml+xml, etc). Other content types will be covered in SSP: Adjuncts. Clients are allowed to guess the returned content type.
The resulting representation will contain:
- Optional, one link identified by the relation new_entry (rel=”new_entry”).
- Zero or more entries identified according to the hAtom specification.
- Optional, for each entry one link identified by the relation edit_entry (rel=”edit_entry”).
Adding an Entry
The client may make a GET request to the new_entry URL, requesting a representation for the purpose of creating a new entry. Typically the request will be for an HTML content type for display in a Web browser.
The client may make a POST request to the new_entry URL in order to create a new entry. The request may include, but is not limited to the following fields:
- title — string of text used for the title of the entry.
- content — the content of the entry (see below).
- author — URL identifying the author of the entry (recommended: the author’s OpenID identity URL).
- status — the status, either ‘published’ or ‘draft’ (default is ‘draft’).
The client may send content in any media type supported by the server, as described in the hForm protocol. If the media type is unspecified, for example, when using application/x-www-form-urlencoded, the server interprets the content as text. The server may render content in a different format, for example, accepting Markdown content and for rendering as HTML.
The server may return any applicable HTTP status code. If the server returns the HTTP status 303 (See Other), the client may assume that the Location header refers to the edit_entry URL associated with the new entry.
Changing an Entry
The client may make a GET request to the edit_entry URL, requesting a representation for the purpose of changing an existing entry. Typically the request will be for an HTML content type for display in a Web browser.
The client may make a POST request to the edit_entry URL in order to change an existing entry. The request may include any field allowed when creating a new entry. The server may not change the value of any field unless that field appears in the request, or its value is derived from another field appearing in the request.
The server may return any applicable HTTP status code.
Deleting an Entry
Follow the same procedure as when changing an entry, but set the status field to the value ‘delete’. The server will ignore all other fields in the request.
The server may return any applicable HTTP status code.
Authentication
Endnote that should come first: This “spec” was written in all of fifteen minutes, so you’ll have to excuse the brief writing style, narrowing down of the editable fields set, and the general lack of references, appendixes, or any examples of over-the-wire messages. The SPP working group will address these matters in due time.
Second endnote: No envelopes were harmed in the production of this specification.
Turulcsirip - Gábor
Eric Allam
Assaf
Gabe