Atom Publishing Protocol im wirklichen Leben

Question

Ich weiß, dass einige große Spieler haben es angenommen und sind tatsächlich einige ihrer Dienste in APP-konforme Weise bereits offengelegt. Allerdings habe ich in diesem Bereich nicht viele andere (kleinere) Spieler gefunden. Kennen Sie eine Webanwendung/einen Dienst, der APP als öffentliches API-Protokoll verwendet? Was ist Ihre eigene Übernahme von AtomPub? Haben Sie praktische Erfahrungen damit? Was sind seine Einschränkungen und Nachteile? Bevorzugen Sie AtomPub als REST-Stil oder haben Sie einen anderen Favoriten? Und warum?

Ich weiß, das sind viele Fragen, nicht nur eine. Die Sache, an der ich mich hier interessiere, ist jedoch einfach: Wie ist der APP-Standard auf den Markt gekommen und wie sieht er insbesondere bei Webentwicklern aus?

Answer 1

Meine eigene Forschung bisher:

• Wordpress unterstützt AtomPub als API-Protokoll seit Version 2.3
• GData ist wahrscheinlich die größte Schuss in den AtomPub Feld bisher
• Habari - viel versprechende neue Blogging-System fördert APP als eine seiner wichtigsten Funktionen
• BlogSvc.net - ein AtomPub Server, Blog-Engine für .NET Plattform geschrieben in C#
• Jangle - Open-Source-Projekt entworfen API-Zugriff auf Library System

Answer 2

Es gibt auch mod_atom zu erleichtern - ein Apache-Modul, das speichert Einträge im Dateisystem.

Answer 3

Das letzte Mal, als ich überprüfte (2007 oder so) war Atompub ziemlich komplex zu implementieren. Während du während der Mittagspause etwas zusammenpeitschen kannst, das gültige Atom-Feeds ausgibt, war die Implementierung von AtomPub ein ziemlich großes Unterfangen.

Das könnte sich aufgrund besserer Bibliotheken und Tools geändert haben, aber es könnte immer noch zu komplex sein, um von kleineren Seiten implementiert zu werden, nur weil es cool ist.

Und das Fehlen von Killer-AtomPub-Client-Anwendungen stellt Serverbetreiber nur wenig oder gar nicht unter Druck, eine AtomPub-Schnittstelle anzubieten.

Answer 4

Das Unternehmen, für das ich arbeite, entwickelt viele REST-konforme Dienste. Allerdings stellt keiner von ihnen öffentliche APIs zur Verfügung (in dem Sinne, dass alle Dienste intern von unseren eigenen Clients konsumiert werden). Der Grund, warum wir uns für den architektonischen REST-Stil entschieden haben, war, dass wir wollten, dass unsere Dienstleistungen leicht konsumierbar sind und vor allem gut skalieren.

Aus meiner eigenen praktischen Erfahrung bin ich zu dem Schluss gekommen, dass HTTP + ATOM Syndication Format eine gute Idee ist, vorausgesetzt, Sie wollen die Dinge flexibel halten uniformes Parsen usw.). ATOM stellt sicher, dass jeder die Nutzlast einheitlich und ohne Mehrdeutigkeit interpretiert.

Wenn man jedoch keine solch komplexen Anforderungen hat oder solche Anforderungen nicht voraussieht, könnte das ATOM-Format ein wenig Overhead sein. (Zum Beispiel sind Elemente wie Autor, Titel usw. in der Blog-/RSS-Welt sinnvoller und möglicherweise in Ihrer speziellen Problemdomäne nicht sinnvoll).

Auch wenn das Ziel ist, nur Datenstrukturen an einem Ende zu serialisieren und am anderen Ende zu rekonstruieren, dann haben die meisten Web-Frameworks (wie WCF) benutzerdefinierte Formate, die ansprechender sind.

Also meiner Meinung ATOM Pub ist gut, wenn Sie Flexibilität in Bezug auf Datendarstellung brauchen und wenn das Spielfeld mit verschiedenen Arten von Client riesig ist.

Wenn Sie jedoch gute Kenntnisse über potenzielle Clients und Server/Client-Nutzungsmuster haben, können benutzerdefinierte Formate eine gute Idee sein.

Wenn der Client browserbasiert ist, sind Formate wie JSON sehr ansprechend.

Hoffe das beantwortet Ihre Frage.