Форматирование odata atompub: приложение/xml против приложения/Zip
Вопрос
Глядя на ответы от некоторых каналов ODATA, я увидел, что их структуры немного разные в зависимости от того, есть ли у них тип контента для приложения/XML или приложения/Zip. Вот два примера:
- Приложение/Zip
<content type="application/zip" /> <m:properties> <d:Id>Simple.Data.Core</d:Id> </m:properties
- Приложение/XML
<content type="application/xml"> <m:properties> <d:ProductID m:type="Edm.Int32">1</d:ProductID> </m:properties> </content>
Оба они отправляются в качестве Atompub (схема Stanard RSS, используемая ODATA), но в случае, если содержание имеет тип «Приложение/Zip», M: Element Properties выходит на том же уровне, что и содержание, и если это «приложение/XML», Это поступает как субэлемент «контента». Согласно спецификации Odata на Odata.org, второй формат правильный. Кто -нибудь знает, почему первый формат также используется (и даже понимается клиентами Odata)?
заранее спасибо
Решение
На самом деле оба верны. Первый (со свойствами M: за пределами контента) представляет собой запись ссылки на медиа (MLE) в соответствии с спецификацией Atompub. Формат Odata для MLE описан здесь: http://www.odata.org/developers/protocols/atom-format#representingmedialinkentriesАнкет Второй-нормальная не-млевая сущность.
Другие советы
Я получил следующий ответ в Odata Google Group:
Если тип сущности помечен как вход в ссылку на медиа, то есть он поддерживается медиа, его свойства не присутствуют в элементе Atom: входной элемент. И элемент контента указывает на местоположение, чтобы загрузить поддержку Media. Другим примером такой сущности является коллекция «названия» в канале Netflix.http://odata.netflix.com/v2/catalog/titles? $ top = 1 Вы упомянули ниже, что у вас возникают проблемы с анализом таких типов сущностей в атоме, как вы анализируете корм для атома? Вы используете одну из наших клиентских библиотек или разрабатываете ответ вручную?
Ссылка :http://tools.ietf.org/html/rfc5023#page-25
Phani Raj Yayavaram narasimha