Протокол публикации Atom в реальной жизни

Question

Я знаю, что некоторые крупные игроки приняли его и фактически уже предоставляют некоторые из своих услуг в соответствии с требованиями APP. Тем не менее, я не нашел много других (меньших) игроков на этом поле. Знаете ли вы какое-либо веб-приложение / службу, которая использует APP в качестве публичного протокола API? Что вы думаете о AtomPub? Есть ли у вас практический опыт его использования? Каковы его ограничения и недостатки? Вы предпочитаете AtomPub в качестве стиля REST или у вас есть какой-то другой любимый стиль? И почему?

Я знаю, это много вопросов, а не только один. Здесь меня интересует простота: как стандарт APP появился на рынке и, в частности, как он выглядит в среде веб-разработчиков?

Answer 1

Компания, в которой я работаю, разрабатывает множество сервисов RESTful. Однако ни один из них не предоставляет общедоступных API (в том смысле, что все сервисы внутренне потребляются нашими собственными клиентами). Причина, по которой мы остановились на архитектурном стиле REST, заключалась в том, что мы хотели, чтобы наши услуги были легко потребляемыми и, что более важно, хорошо масштабировались.

Исходя из своего практического опыта, я пришел к выводу, что формат синдикации HTTP + ATOM является хорошей идеей, если вы хотите сохранить гибкость (с точки зрения разной модели контента, присоединения и расширения метаданных, связанных с полезными нагрузками, единообразного анализа и т. Д.), ATOM гарантирует, что каждый интерпретирует полезную нагрузку единообразным образом, не допуская двусмысленности.

Однако, если у кого-то нет таких сложных требований или он не предусматривает таких требований, то формат ATOM может быть немного накладным.(Например, такие элементы, как "Автор", "Заголовок" и т. Д. Имеют больше смысла в мире блогов /RSS и могут не иметь смысла в вашей конкретной проблемной области).

Кроме того, если цель состоит в том, чтобы просто сериализовать структуры данных на одном конце и реконструировать их на другом конце, то большинство веб-сред (например, WCF) имеют собственные форматы, которые являются более привлекательными.

Так что, на мой взгляд, ATOM Pub - это хорошо, если вам нужна гибкость с точки зрения представления данных и если игровое поле огромно для разных типов клиентов.

Однако, если вы хорошо знакомы с потенциальными клиентами и схемами использования сервера / клиента, тогда лучше подойти к пользовательским форматам.

Если клиент основан на браузере, такие форматы, как JSON, очень привлекательны.

Надеюсь, что это ответ на ваш вопрос.

Answer 2

Также есть mod_atom - модуль Apache, который хранит записи в файловой системе.

Answer 3

Мои собственные исследования:

• Wordpress поддерживает AtomPub в качестве протокола API начиная с версии 2.3
• GData, вероятно, самый большой выстрел в области AtomPub до сих пор
• Habari - новая многообещающая система блогов продвигает приложение как одну из его основных функций
• BlogSvc.net - сервер AtomPub, движок блогов для платформы.NET, написанный на C#
• Jangle - проект с открытым исходным кодом, предназначенный для облегчения доступа API к библиотечным системам

Answer 4

В прошлый раз, когда я проверял (2007 или около того), Atompub был довольно сложен в реализации. В то время как вы можете собрать воедино что-то, что испускает действительные потоки Atom во время обеденного перерыва, внедрение AtomPub было довольно большой задачей.

Это могло бы измениться из-за лучших библиотек и инструментов, но все же это могло бы быть слишком сложно, чтобы быть реализованным меньшими сторонами только потому, что это круто.

А отсутствие клиентских приложений AtomPub-убийц практически не заставляет операторов серверов предлагать интерфейс AtomPub.