一部の大手企業はこれを採用しており、実際に一部のサービスを APP 準拠の方法で公開していることは知っています。しかし、私はこの分野で他に多くの (より小さな) プレーヤーを見つけていません。APP をパブリック API プロトコルとして使用する Web アプリケーション/サービスを知っていますか? AtomPub についてどう思いますか? 実際に使用した経験はありますか？その制限と欠点は何ですか? REST スタイルとして AtomPub が好きですか、それとも他に好きなスタイルがありますか? なぜ？
私は知っています、これらは多くの質問であり、1つだけではありません. ここで私が興味を持っていることは単純です - APP 標準はどのように市場に出回ったのか、特に Web 開発者の間での採用はどのように見えるのでしょうか?
私が働いている会社は、多くのRESTfulサービスを開発しています。ただし、それらのいずれもパブリックAPIを公開していません（すべてのサービスが内部で独自のクライアントによって消費されるという意味で）。私たちがRESTアーキテクチャスタイルを採用した理由は、サービスを簡単に利用でき、さらに重要なことに拡張性を高めることを望んでいたためです。
私自身の実際の経験から、物事を柔軟に保ちたいのであれば、HTTP + ATOMシンジケーション形式が良い考えであるという結論に達しました（異なるコンテンツモデル、ペイロードに関連付けられたメタデータの添付と拡張、均一な解析など） 。ATOMは、あいまいさの余地がなく、すべての人がペイロードを均一に解釈することを保証します。
ただし、そのような複雑な要件がない場合、またはそのような要件を予測できない場合、ATOM形式は少しオーバーヘッドになる可能性があります。（たとえば、Author、Titleなどの要素は、ブログ/ RSSの世界ではより意味があり、特定の問題ドメインでは意味がない場合があります）。
また、一方の端でデータ構造をシリアル化し、もう一方の端でデータ構造を再構築することが目標である場合、ほとんどのWebフレームワーク（WCFなど）には、より魅力的なカスタム形式があります。
したがって、私の意見では、ATOM Pubは、データ表現の観点から柔軟性が必要な場合や、さまざまな種類のクライアントで競争の場が広大な場合に適しています。
ただし、潜在的なクライアントとサーバー/クライアントの使用パターンについて十分な知識がある場合は、カスタム形式を使用することをお勧めします。
クライアントがブラウザベースの場合、JSONのようなフォーマットは非常に魅力的です。
これがあなたの質問に答えることを願っています。
これまでの私自身の研究：
ファイルシステムにエントリを保存する Apache モジュールであるmod_atomもあります。
前回確認したとき (2007 年くらい)、Atompub の実装はかなり複雑でした。昼休み中に有効な Atom フィードを発行するものをまとめることはできますが、AtomPub の実装はかなりの作業でした。
それはより良いライブラリとツールのために変わったかもしれませんが、それがクールであるという理由だけで小規模な側で実装するには複雑すぎるかもしれません.
また、強力な AtomPub クライアント アプリケーションがないため、サーバー オペレーターに AtomPub インターフェースを提供するプレッシャーはほとんどまたはまったくありません。