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

Question

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

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

Answer 1

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

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

Answer 2

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

Answer 3

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

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

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

Answer 4

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

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

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

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

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

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

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

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