Форматирование OData AtomPub: приложение / xml или приложение / zip - PullRequest
1 голос
/ 05 сентября 2011

Просматривая ответы от некоторых каналов OData, я обнаружил, что их структуры немного различаются в зависимости от того, установлен ли для них тип содержимого application / xml или application / zip.Вот два примера:

  1. application / zip
<content type="application/zip" /> 
<m:properties>
  <d:Id>Simple.Data.Core</d:Id> 
</m:properties
  1. application / xml
<content type="application/xml">
<m:properties>
  <d:ProductID m:type="Edm.Int32">1</d:ProductID>
</m:properties>
</content>

Оба из нихотправляются как AtomPub (стандартная схема RSS, используемая OData), но в случае, если контент имеет тип «application / zip», элемент m: properties находится на том же уровне, что и контент, а если это «application / xml», то он выглядит какподэлемент «контента».Согласно спецификации OData на odata.org, второй формат правильный.Кто-нибудь знает, почему первый формат также используется (и даже понимается клиентами OData)?

Заранее спасибо

Ответы [ 2 ]

1 голос
/ 06 сентября 2011

На самом деле оба верны. Первый (с m: свойствами вне содержимого) представляет запись медиа-ссылки (MLE) согласно спецификации ATOMPUB. Формат OData для MLE описан здесь: http://www.odata.org/developers/protocols/atom-format#RepresentingMediaLinkEntries. Второй - это нормальный объект без MLE.

0 голосов
/ 06 сентября 2011

Я получил следующий ответ в OData Google group :

Если тип сущности помечен как запись медиа-ссылки, т.е. он поддерживается медиа, его свойства отсутствуют в элементе atom: entry И элемент контента указывает на место, откуда загружается носитель с поддержкой. Другим примером такой сущности является коллекция 'Titles' в ленте Netflix. http://odata.netflix.com/v2/Catalog/Titles?$top=1 Вы упоминаете ниже, что у вас возникают проблемы с анализом таких типов объектов в Atom. Как вы анализируете ленту ATOM? Вы используете одну из наших клиентских библиотек или анализируете ответ вручную?

Ссылка: http://tools.ietf.org/html/rfc5023#page-25

Фани Радж Яяварам Нарасимха

...