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

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

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

ОТВЕТЫ

Ответ 1

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

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

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

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

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

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

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

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

Ответ 2

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

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

Ответ 3

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

Ответ 4

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

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

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