Entwurfsprinzipien

(Auszug aus "Newsfeeds mit RSS und Atom" von Heinz Wittenbrink, erschienen bei Galileo Press, 2005)

Die Ziele des Atom Publishing Protocols, das oft auch als Atom API bezeichnet wurde, überlappen sich mit den Zielen des Atom Syndication Format. Das Protokoll soll gänzlich Anbieter-neutral und von jedem implementierbar sein; es soll darüber hinaus auch von jedem Anbieter, der in Frage kommt, tatsächlich implementiert werden. Es muss also auch auf gehosteten Accounts funktionieren und für Benutzer zugänlich sein, die ein .htaccess-File nicht verändern können. Der Zugang soll über eine reine CGI-Funktionalität möglich sein. Hinzu kommt, dass das Protokoll beliebig und frei erweiterbar sein muss. Es soll wie das Syndikationsformat komplett und sauber spezifiziert sein. Außerdem soll es keine Sicherheitslücken aufweisen.

Das Atom Publishing Protocol ist ein REST API und verzichtet auf die Verwendung von SOAP. Dafür gibt es wichtige Günde. Mark Pilgrim nennt diese: Man benötigt keinen zusätzlichen Wrapper, da das Atom-Format selbst bereits einen Wrapper um Inhalte in einem anderen Format definiert. Für die vorhandenen Anbieter genügen die Authentisierungs-Mechanismen, die HTTP anbietet; keiner von ihnen hat an einem stärkeren oder exotischeren Verfahren Interesse. Außerdem benötigen die vorhandenen Anbieter auch kein Verfahren, das vom HTTP-Transportmechanismus unabhängig ist.

Es stellt sich auch die Frage, warum zum Aktualisieren von Websites nicht das bereits vorhandene und gründlich spezifizierte WEBDAV-Protokoll verwendet werden soll. Um diese Frage zu beantworten, verweist Pilgrim auf die spezifischen Bedingungen, unter denen das Atom Publishing Protocol verwendet werden soll. Es wird entworfen, um episodische Websites zu bearbeiten, nicht beliebige Dokumente auf einem Server. Es soll die Kommunikation mit verschiedenen anwenderspezifischen Backends durch einen gemeinsamen API ermöglichen, nicht mehr. Und es muss ausschließlich über CGI funktionieren, damit man mit ihm auch auf gehosteten Sites arbeiten kann, die keinen Zugang zu einem .htaccess-File erlauben.

Das Atom API wird über das Editieren hinaus noch weitere Funktionen anbieten. Dazu werden das Posten von Kommentaren sowie das Managen von Benutzern, Benutzer-Präferenzen, Site-Templates und Kategorien gehören.

Noch offen ist derzeit (Mai 2005) vor allem, wie das Publishing Protocol Collections von Einträgen behandeln will (vgl. Getting ready for the protocol discussion).

Zur Architektur des APIs gehört:

  • Es soll mit Literalen funktionieren, die das Dokument repräsentieren, und nicht Remote Procedure Calls verwenden. Diese Anforderung deckt sich mit der Anforderung an das Atom-Syndikationsformat, zugleich als Autoren- und als Publikationsformat zu funktionieren.
  • Es soll sich um ein schlankes und wohldefiniertes Format handeln, das nicht daran scheitert, zu viele Features für zu viele unterschiedliche Anforderungen zu definieren. Insbesondere soll es keine neue Form des WEBDAV-Protokolls sein.
  • Das Format soll darüber hinaus die Möglichkeiten der vorhandenen Webarchitektur nutzen; es soll also alle Möglichkeiten ausschöpfen, die HTTP und XML bieten. Im Kern, so heißt es in der Spezifikation, beschreibt das Atom Publishing Protocol den Transport von Repräsentationen im Atom-Format über das HTTP-Protokoll.
  • Schließlich ergibt sich aus den Sicherheitsanforderungen, dass bei der Verwendung des Atom-APIs Passwörter nicht im Klartext übertragen werden sollen.
  • Im Gegensatz zu anderen APIs soll das Atom API darüber hinaus auch über ein standardisiertes Verfahren zur Entdeckung des APIs (API discovery) verfügen. Bei den vorhandenen APIs ist es dem Benutzer überlassen, den API des Service zu finden. Funktionen sind zum Teil undokumentiert.

Die Entdeckung des Atom APIs setzt nur voraus, dass ein Benutzer den URI eines HTML-Webdokuments kennt, über das das API erreichbar ist. Ein Element link als Nachkomme von feed zeigt auf eine service.feed- oder Introspektionsdatei. Diese Introspektionsdatei enthält eine Liste der unterstützten Funktionen und Erweiterungen. Das Introspektionsdokument ist ein einfaches wohlgeformtes XML-Dokument. Jeder Anbieter kann das Format dieses Dokuments erweitern, indem er den XML-Namensraum-Mechanismus verwendet.

   

<< zurück vor >>

 

 

 

Tipp der data2type-Redaktion:
Zum Thema Newsfeeds mit RSS und Atom bieten wir auch folgende Schulungen zur Vertiefung und professionellen Fortbildung an: