Знакомство с протоколом публикации Atom, Часть 1: Создание и редактирование Web-ресурсов при помощи протокола публикации Atom

Вводный курс по основным операциям протокола

Протокол публикации Atom (Atom Publishing Protocol) является важным новым стандартом публикации и управления контентом. В данной статье проводится качественное исследование протокола и его основных возможностей и характеристик.

Джеймс Снелл, разработчик программного обеспечения, IBM

Джеймс Снелл (James Snell) является членом исследовательской лаборатории IBM WebAhead, занимающейся разработкой опытных образцов стандартов и технологий программного обеспечения, находящегося в стадии создания, для собственных нужд IBM. Его научно-исследовательские интересы охватывают широкий круг направлений современных технологий, а именно Atom, AJAX, REST, Open Source, персональные издательские системы, семантические и ситуационные Web-приложения. Он является активным участником проекта Apache Abdera, находящегося в настоящее время на этапе разработки и нацеленного на создание высокоэффективной и функционально законченной реализации стандартов формата синдикации Atom и протокола публикации Atom.



29.03.2007

За последние несколько лет технология публикации Web-контента приобрела большую значимость и в сети Интернет, и за файерволом. В июле 2005 г. рабочая группа по стандартам для сети Internet (IETF) (известная как "atompub") опубликовала первую из двух спецификаций стандартов, предназначенную для предоставления "формата для представления лент (feed) и протокола для редактирования таких Web-ресурсов, как блоги, сетевые журналы, вики, и ресурсов с аналогичным содержимым". Формат синдикации Atom, известный всем как Atom 1.0, уже используется миллионами Web-сайтов и поддерживается всеми основными платформами синдикации. В настоящее время, спустя год, близится к завершению работа над второй из двух спецификаций - протоколом публикации Atom.

Протокол публикации Atom - это основанный на HTTP подход к созданию и редактированию контента Web-ресурсов. Он разрабатывался на основе идеи использования основных операций, предоставляемых протоколом HTTP (а именно GET, PUT, и DELETE) для передачи элементов лент и входных документов Atom 1.0, отображающих такие элементы, как сообщения блогов, подкасты (podcasts), страницы вики, календари и так далее.

Дальнейшее исследование представляет собой вводный курс по основным операциям протокола. Данное обсуждение предполагает, что Вы обладаете хорошими знаниями в области синдикации контента с использованием формата синдикации Atom 1.0 и начальными знаниями по HTTP. Как Вы уже прочитали в данном обзоре, я рекомендую Вам держать под рукой спецификации Atom 1.0 (RFC 4287) и HTTP 1.1 (RFC 2616), и использовать их как руководство по различным обсуждаемым элементам и методам. Если Вы не имеете даже малейшего представления о формате Atom, то я рекомендую Вам посмотреть статью, написанную мной для developerWorks в прошлом году, "Обзор формата синдикации Atom" (Смотрите Ресурсы).

Обзор высокого уровня

В основе протокола публикации Atom лежит идея коллекций доступных для редактирования ресурсов, представленных лентами и входными документами Atom 1.0. У коллекции есть свой уникальный URI. HTTP запрос GET на этот URI возвращает документ с лентами Atom. Для создания новых сообщений в данной ленте, клиенты отправляют HTTP запросы POST на URI коллекции. Данным, вновь созданным, сообщениям будут присвоены уникальные URI для редактирования. Чтобы изменить эти сообщения, клиент просто получает источник из коллекции, вносит изменения, и возвращает его обратно. Удаление сообщений из ленты выполняется простой отправкой HTTP запроса DELETE на соответствующий URI для редактирования. Все операции выполняются простым использованием HTTP запросов и могут быть реализованы при помощи любого простого текстового редактора и командной строки.

Рисунок 1. Протокол публикации Atom использует простые методы HTTP для публикации и управления контентом.
Обзор протокола публикации Atom
Листинг 1. Взаимодействие с конечной точкой публикации Atom с использованием curl с открытым исходным кодом HTTP клиента.
curl -s -X POST -data-binary @entry.xml http://example.org/atom/entries
curl -s -X GET http://example.org/atom/entries/1
curl -s -X PUT -data-binary @entry.xml http://example.org/atom/entries/1
curl -s -X DELETE http://example.org/atom/entries/1

Определение доступных коллекций

Первым шагом в использовании любого сервиса с поддержкой APP является определение доступных коллекций, и какие типы ресурсов могут содержаться в данных коллекциях. Спецификация протокола Atom определяет формат XML как служебный документ, который может использоваться клиентом для анализа конечной точки.

Для получения служебного документа, отправьте HTTP запрос GET на URI служебного документа.

Листинг 2. Получение служебного документа APP с сервера.
GET /servicedocument HTTP/1.1
Host: example.org

Как показано в листинге 3, сервер должен ответить передачей служебного документа, в котором перечислены доступные клиенту коллекции.

Листинг 3. Простой служебный документ APP
HTTP/1.1 200 OK
Date: ...
Content-Type: application/atomserv+xml; charset=utf-8
Content-Length: nnn

<service xmlns="..." xmlns:atom="http://www.w3.org/2005/Atom">
  <workspace>
    <atom:title>My Weblog</atom:title>
    <collection href="http://www.example.org/blog/entries">
      <atom:title>Entries</atom:title>
      <accept>entry</accept>
    </collection>
    <collection href="http://www.example.org/blog/photos">
      <atom:title>Photos</atom:title>
      <accept>image/*</accept>
    </collection>
  </workspace>
</service>

Каждый элемент коллекции, указанный в служебном документе представляет собой контейнер, в котором может храниться какая-либо часть контента. Элементы рабочего пространства в документе могут использоваться только для объединения взаимосвязанных коллекций в логические множества. Например, у одного пользователя может быть несколько учетных записей в данном сервисе блогов, предоставляющем различные контейнеры для сообщений блогов, загруженных файлов, закладок, и так далее. Каждый сервис может быть представлен в служебном документе как отдельное рабочее пространство.

Элемент коллекции предоставляет адрес коллекции (атрибут href) и перечень типов контента, который можно добавить в коллекцию (определяется MIME-типом в принимающих элементах). В примере, показанном в листинге 3, есть две коллекции, одна из которых принимает только входные документы Atom, а вторая - только файлы изображений (например, PNG, GIF, JPEG, и другие).

Добавление сообщения в коллекцию

Как показано в листинге 4, если у Вас есть адрес коллекции, то для добавления новых ресурсов используется HTTP метод POST.

Листинг 4. Размещение сообщения в коллекции APP
POST /blog/entries HTTP/1.1
Host: www.example.org
Content-Type: application/atom+xml; charset=utf-8
Content-Length: nnn

<?xml version="1.0" ?>
<entry xmlns="http://www.w3.org/2005/Atom">
  <title>Atom-Powered Robots Run Amok</title>
  <link href="http://example.org/2003/12/13/atom03"/>
  <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
  <updated>2003-12-13T18:30:02Z</updated>
  <author><name>James</name></author>
  <summary>Some text.</summary>
</entry>

В примере, показанном в листинге 4, организовано добавление входного документа Atom в коллекцию, расположенную по адресу http://example.org/blog/entries. URI коллекции получен из служебного документа, показанного в листинге 3. Обратите внимание на то, что размещаемое (публикуемое) сообщение должно быть валидно - то есть иметь идентификатор, автора и обновленные элементы, даже если большинство серверов APP предпочтет проигнорировать и перезаписать предоставленные клиентом значения.

Успешный ответ на запрос POST, показанный в листинге 5, предоставляет клиенту важную информацию: статус запроса (код ответа HTTP) и адрес только что созданного ресурса, содержащиеся в заголовке Location.

Листинг 5. Ответ на успешное выполнение операции POST
HTTP/1.1 201 Created
Date: nnnn
Content-Type: application/atom+xml; charset=utf-8
Content-Location: /blog/entries/1
Location: /blog/entries/1
ETag: "/blog/entries/1?1"
Last-Modified: Sat, 12 Aug 2006 13:40:03 GMT

<?xml version="1.0" ?<
<entry xmlns="http://www.w3.org/2005/Atom" >
  <id>tag:example.org,2006:/blog/entries/1</id>
  <title>Atom-Powered Robots Run Amok</title>
  <link href="http://example.org/2003/12/13/atom03"/>
  <link rel="edit" href="http://example.org/blog/entries/1" />
  <updated>2006-08-12T13:40:03Z</updated>
  <author><name>James M Snell</name></author>
  <summary>Some text.</summary>
</entry>

Так как некоторые серверы APP могут изменять различные ключевые аспекты сообщения (например, идентификатор, автора или обновленные элементы), то в возвращаемом сервером ответе может содержаться копия того сообщения, которое фактически было добавлено в коллекцию. Это позволяет клиентам сопоставить отправленное на сервер сообщений с фактически созданным сообщением.

Перечень сообщений в коллекции

Как показано в листинге 6, после добавления сообщения в коллекцию, клиенты могут получить перечни ее ресурсов, направив запрос GET на URI коллекции.

Листинг 6. Получение ленты коллекции.
GET /blog/entries HTTP/1.1
Host: example.org

Как показано в листинге 7, ответом на данный запрос будет документ с лентами Atom, в котором каждое сообщение из набора будет представлять только один ресурс коллекции.

Листинг 7. Документ с лентами Atom для коллекции APP.
HTTP/1.1 200 OK
Date: ...
Content-Type: application/atom+xml; charset=utf-8
Content-Length: nnn
ETag: "/blog/entries?132"
Last-Modified: Sat, 12 Aug 2006 13:40:03 GMT

<feed xmlns="http://www.w3.org/2005/Atom" 
      xml:base="http://example.org/blog/entries">
  <id>http://example.org/blog/entries</id>
  <title>My Blog Entries</title>
  <updated>2006-08-12T13:40:03Z</updated>
  <link rel="self" href="/blog/entries" />
  <link href="http://blog.example.org" />
  <entry>
    <id>tag:example.org,2006:/blog/entries/1</id>
    <title>Atom-Powered Robots Run Amok</title>
    <link href="http://example.org/2003/12/13/atom03"/>
    <link rel="edit" href="http://example.org/blog/entries/1" />
    <updated>2006-08-12T13:40:03Z</updated>
    <author><name>James</name></author>
    <summary>Some text.</summary>
  </entry>
  <entry>
     ...
  </entry>
  ...
</feed>

Интерпретировать ленту, возвращенную коллекцией, можно как что-то типа индексов данной коллекции, подобно тому, как выполняется команда "dir" или команда "ls" в файловой системе.

Очередность самих сообщений зависит от значения каждого обновленного элемента сообщения - те сообщения, которые были изменены последними, представлены в начале списка. Кроме того, как показано в листинге 8, список сообщений может простираться на несколько документов с лентами Atom, связанных между собой при помощи, так называемых, страничных ссылок.

Листинг 8. Часть ленты, отражающая использование страничных ссылок
<feed xmlns="http://www.w3.org/2005/Atom" 
      xml:base="http://example.org/blog/entries?page2">
  <link rel="next" href="entries?page3" />
  <link rel="previous" href="entries?page1" />
  ...

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

Редактирование сообщения

Чтобы отредактировать сообщение, клиент сначала должен получить редактируемое представление этого сообщения. В листинге 9 показано, что для выполнения поставленной задачи, необходимо направить запрос GET на URI для редактирования участника. Фактически это напоминает открытие документа в текстовом редакторе, перед тем как Вы начнете его редактировать.

Листинг 9. Получение доступного для редактирования представления ресурса.
GET /blog/entries/1 HTTP/1.1
Host: example.org

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

Листинг 10. Входной документ Atom, отображающий редактируемый ресурс
HTTP/1.1 200 OK 
Date: nnn
Content-Type: application/atom+xml; charset=utf-8
Content-Length: nnn
ETag: "/blog/entries/1?1"
Last-Modified: Sat, 12 Aug 2006 13:40:03 GMT

<?xml version="1.0" ?>
<entry xmlns="http://www.w3.org/2005/Atom" >
  <id>tag:example.org,2006:/blog/entries/1</id>
  <title>Atom-Powered Robots Run Amok</title>
  <link href="http://example.org/2003/12/13/atom03"/>
  <link rel="edit" href="http://example.org/blog/entries/1" />
  <updated>2006-08-12T13:40:03Z</updated>
  <author><name>James</name></author>
  <summary>Some text.</summary>
</entry>

После получения доступного для редактирования представления, клиент может внести любые изменения в выбранное сообщение (в разумных пределах), и затем, чтобы выполнить обновление, отправить запрос PUT на URI для редактирования сообщения (Листинг 11).

Листинг 11. Отправка на сервер измененного сообщения Atom.
PUT /blog/entries/1 HTTP/1.1
Host: example.org
Content-Type: application/atom+xml; charset=utf-8
Content-Length: nnnn
If-Match: "/blog/entries/1?1"
If-Unmodified-Since: Sat, 12 Aug 2006 13:40:03 GMT

<?xml version="1.0" ?>
<entry xmlns="http://www.w3.org/2005/Atom" >
  <id>tag:example.org,2006:/blog/entries/1</id>
  <title>Atom-Powered Robots Run Crazy</title>
  <link href="http://example.org/2003/12/13/atom03"/>
  <link rel="edit" href="http://example.org/blog/entries/1" />
  <updated>2006-08-12T13:40:03Z</updated>
  <author><name>John</name></author>
  <summary>Some different text.</summary>
</entry>

Обратите внимание на использование заголовков If-Match и If-Unmodified-Since в запросе PUT. Будучи необязательным, использование этих заголовков позволяет реализациям APP защищать от перезаписывающих изменений, которые могут вноситься в ресурс другими клиентами. Если ни одно из этих условий не выполняется, то сервер должен отклонить запрос и уведомить клиентов о том, что вероятно произошел конфликт с тем ресурсом, который они пытаются изменить. Если условия выполняются, то сервер считает, что передаваемые клиентом изменения допустимы и возвращает успешный ответ.

Удаление сообщения

Если клиенту необходимо удалить ресурс из коллекции, то он отправляет запрос DELETE на URI для редактирования (смотрите листинг 12).

Листинг 12. Удаление ресурса из коллекции
DELETE /blog/entries/1 HTTP/1.1
Host: example.org

В случае успешного удаления, сообщение больше не будет появляться в коллекциях ленты Atom и не будет доступно для редактирования.

Добавление мультимедийных ресурсов в коллекцию

В APP коллекции можно также добавлять и любые мультимедийные ресурсы, например, фотографии, документы, аудиозаписи, и другие. Спецификация APP называет элементы такого типа сообщениями со ссылкой на мультимедийные ресурсы потому, что при добавлении таких ресурсов в коллекцию сервер создает входной документ Atom, привязанный к мультимедийному ресурсу, размещенному клиентом.

Хотя первоначально протокол публикации Atom и разрабатывался исключительно для обеспечения авторов сетевых дневников возможностью загружать мультимедийные объекты, которые они хотят использовать в своих сообщениях, но, благодаря его способности поддерживать любые мультимедийные ресурсы, он идеально подходит для большого числа приложений, в том числе:

  • Подкастинг
  • Видео-блоги
  • Библиотеки фотографий
  • Вики и ситуационные приложения
  • Управление документами
  • Информационные архивы XML
  • Распространение программного обеспечения
  • Приложения по оптимизации бизнес-процессов (например, офисные пакеты)
  • И многие другие...

Для создания сообщения со ссылкой на мультимедийные ресурсы, клиент отправляет запрос POST на URI коллекции, но вместо включения в состав входного документа Atom, клиент включает отображение привязанного мультимедийного ресурса (листинг 13).

Листинг 13. Размещение бинарного графического файла в коллекции APP
POST /blog/photos HTTP/1.1
Host: example.org
Content-Type: image/png
Content-Length: nnnn
Slug: A trip to the beach

{binary image data}

Если коллекция обладает возможностью хранения типа мультимедийного ресурса, присланного клиентом, то она хранит его и создает связку входного документа Atom с мультимедийным ресурсом (смотрите листинг 14). Заголовок Slug, содержащийся в запросе, является новым заголовком элемента HTTP, привнесенным протоколом публикации Atom, и применяемым для реализации связи между обычным названием и ресурсом, которая может использоваться для решения различных задач при создании и управлении ресурсом. Например, сервер может использовать значение заголовка при создании URI ресурса-участника или при присвоении значения элемента заголовка во входном документе Atom. Заголовок Slug может использоваться при размещении и мультимедийных ресурсов, и сообщений Atom, но чаще всего применяется в первом случае.

Листинг 14. Сообщение со ссылкой на мультимедийный ресурс, созданное в ответ на мультимедийное сообщение
HTTP/1.1 201 Created
Date: nnnn
Content-Location: /blog/photos/a_trip_to_the_beach
Location: /blog/photos/a_trip_to_the_beach
Content-Type: application/atom+xml; charset=utf-8
Content-Length: nnnn
Slug: A trip to the beach
ETag: "/blog/photos/a_trip_to_the_beach?1"
Last-Modified: Sat, Aug 12 2006 14:11:04 GMT

<?xml version="1.0"?>
<entry xmlns="http://www.w3.org/2005/Atom">
  <id>tag:example.org,2006:/blog/photos/a_trip_to_the_beach</id>
  <title>A trip to the beach</title>
  <link rel="edit" 
    href="http://example.org/blog/photos/a_trip_to_the_beach" />
  <link rel="edit-media" type="image.png" 
    href="http://example.org/blog/photos/a_trip_to_the_beach?media" />
  <updated>2006-08-12T14:11:04Z</updated>
  <author><name>James</name></author>
  <summary>A trip to the beach</summary>
  <content type="image/png" 
    src="http://blog.example.org/photos/a_trip_to_the_beach" />
</entry>

В сообщениях со ссылками на мультимедийные ресурсы всегда будет присутствовать элемент контента, src-атрибут которого содержит URI созданного мультимедийного ресурса. Помните о возможности использования этого URI для организации общедоступных ссылок на мультимедийный ресурс. При помощи отдельной ссылки для редактирования мультимедийного ресурса Вы можете определить URI, который можно будет использовать для обновления мультимедийного ресурса.

Редактирование мультимедийных ресурсов

Редактирование мультимедийного ресурса, размещенного в коллекции, в целом аналогично редактированию сообщения Atom. Первым шагом является получение редактируемой версии ресурса, отправив запрос GET на URI, указанный ссылкой для редактирования мультимедийного ресурса (листинг 15).

Листинг 15. Получение редактируемого представления мультимедийного ресурса
GET /blog/photos/a_trip_to_the_beach?media HTTP/1.1
Host: example.org

По возвращении редактируемого представления клиент вносит необходимые изменения и отправляет запрос PUT на URI для редактирования мультимедийного ресурса (листинг 16).

Листинг 16. Изменение мультимедийного ресурса
PUT /blog/photos/a_trip_to_the_beach?media HTTP/1.1
Host: example.org
Content-Type: image/png
Content-Length: nnn

{new binary image data}

Защита коллекций

Хотя протокол публикаций Atom и не требует от приложений использования аутентификации, однако настоятельно рекомендуется, чтобы приложения применяли ее для предотвращения создания и изменения элементов коллекций злоумышленными клиентами. По меньшей мере, приложения должны уметь применять базовую аутентификацию HTTP и соединения TLS/SSL. Но на практике клиенты APP вероятно предусматривают различные механизмы аутентификации. Однако, несмотря на тип используемой аутентификации, для определения типа выбранной аутентификации серверы должны применять стандартные возможности HTTP .

Например, как показано в листинге 17, если сервер получает несанкционированный запрос от клиента, то он должен выдать 401 Unauthorized response (Несанкционированный ответ), в котором содержится заголовок WWW-Authenticate (WWW-аутентифицировать).

Листинг 17. Ответ на несанкционированный запрос
HTTP/1.1 401 Unauthorized
Date: nnn
WWW-Authenticate: Basic realm="my blog"

Клиент может повторно послать запрос с соответствующим заголовком Authorization (Авторизация).

Листинг 18: Санкционированный запрос
POST /entries/blog HTTP/1.1
Host: example.org:443
Authorization: Basic SmFtZXM6bm90IG15IHJlYWwgcGFzc3dvcmQgOi0p
...

Использование APP

До сих пор я описывал основные операции протокола публикации Atom, показывая на примерах его основные функции. Однако мною не был рассмотрен ввод протокола публикации Atom в работу. В следующем выпуске данной серии, мною будет проведен подробный анализ нескольких сценариев приложений, использующих протокол корректно в таких очевидных видах приложений, как сетевые дневники, общественные закладки и сборники, и показано в какой-то степени неочевидное применение в приложениях календарного планирования, управления контактами, архивов документов и мультимедиа, управления базами данных и даже архитектуре обслуживания широкого круга запросов.

Кроме того, Вы узнаете, каким образом в настоящее время можно легко реализовать клиента и сервера публикации Atom на Java с использованием Apache Abdera реализации Atom с открытым исходным кодом на основе программного обеспечения Apache и по шагам создадите сервис сервера приложений с поддержкой APP.

Ресурсы

Научиться

Получить продукты и технологии

Обсудить

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=XML
ArticleID=204986
ArticleTitle=Знакомство с протоколом публикации Atom, Часть 1: Создание и редактирование Web-ресурсов при помощи протокола публикации Atom
publish-date=03292007