Atom Publishing Protocol dans la vie réelle

Question

Je sais que certains grands acteurs l'ont embrassé et exposent effectivement certains de leurs services de manière conforme à l'APP, déjà. Cependant, je n'ai pas trouvé beaucoup d'autres (plus petits) joueurs dans ce domaine. Connaissez-vous une application/un service Web qui utilise APP comme protocole API public? Qu'est-ce que votre propre sur AtomPub? Avez-vous des expériences pratiques pour l'utiliser? Quelles sont ses limites et ses inconvénients? Préférez-vous AtomPub comme style REST ou en avez-vous d'autres préférés? Et pourquoi? Je sais, ce sont de nombreuses questions, pas une seule. La chose qui m'intéresse ici est simple, cependant - comment le standard APP a-t-il frappé le marché et en particulier comment cela semble-t-il avec son adoption parmi les développeurs web?

Answer 1

Mes recherches jusqu'à présent:

• Wordpress soutient AtomPub comme protocole API depuis la version 2.3
• GData est probablement le plus grand coup dans le domaine AtomPub jusqu'à présent
• Habari - nouveau système de blogging prometteur favorise APP comme l'une de ses principales caractéristiques
• BlogSvc.net - un serveur AtomPub , moteur de blog pour. NET plate-forme, écrite en C#
• Jangle - un projet open source conçu pour faciliter l'accès aux API à Library Systems

Answer 2

Il y a aussi mod_atom - un module Apache qui stocke des entrées dans le système de fichiers.

Answer 3

La dernière fois que j'ai vérifié (2007 environ), Atompub était assez complexe à implémenter. Alors que vous pouvez assembler quelque chose qui émet des flux Atom valides pendant la pause déjeuner, la mise en œuvre d'AtomPub était une entreprise assez importante.

Cela a peut-être changé en raison de l'amélioration des bibliothèques et des outils, mais il se peut que ce soit trop complexe pour être implémenté par des parties plus petites simplement parce que c'est cool. Et le manque d'applications client AtomPub tueur met peu ou pas de pression sur les opérateurs de serveur pour offrir une interface AtomPub.

Answer 4

La société pour laquelle je travaille développe de nombreux services RESTful. Toutefois, aucun d'entre eux n'expose les API publiques (dans le sens où tous les services sont consommés en interne par nos propres clients). La raison pour laquelle nous avons opté pour le style architectural REST était que nous voulions que nos services soient facilement consommables et, surtout, qu'ils évoluent bien. D'après ma propre expérience pratique, je suis arrivé à la conclusion que le format de syndication HTTP + ATOM est une bonne idée, à condition que vous souhaitiez garder les choses flexibles (En termes de modèle de contenu différent, attacher et étendre les métadonnées associées aux charges utiles, analyse uniforme, etc.). ATOM s'assure que tout le monde interprète la charge utile de manière uniforme sans aucune ambiguïté.

Cependant, si l'on n'a pas de telles exigences complexes ou si l'on ne voit pas de telles exigences, alors le format ATOM pourrait être un peu surchargé. (Par exemple, des éléments tels que Auteur, Titre, etc. ont plus de sens dans le monde des blogs/RSS et peuvent ne pas avoir de sens dans votre domaine de problème particulier).

De plus, si l'objectif est de sérialiser les structures de données à une extrémité et de les reconstruire à l'autre extrémité, la plupart des frameworks Web (comme WCF) ont des formats personnalisés plus attrayants. Donc, à mon avis, ATOM Pub est bon si vous avez besoin de souplesse en termes de représentation des données et si le terrain de jeu est énorme avec différents types de clients. Cependant, si vous avez une bonne connaissance des clients potentiels et des modèles d'utilisation du serveur/client, les formats personnalisés peuvent être une bonne idée.

Si le client est basé sur un navigateur, les formats comme JSON sont très attrayants.

Espérons que cela répond à votre question.