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

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

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

14.12.2008 00:55:47
4 ОТВЕТА

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

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

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

2
5.01.2009 21:04:21

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

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

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

1
18.01.2009 11:16:15

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

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

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

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

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

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

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

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

3
17.02.2009 10:27:28