Я пытаюсь реализовать потребителя odata, в частности, прямо сейчас, связанного с выполнением пакетных операций и наборов изменений, следуя документации odata , по существу, загружается в этот образец многокомпонентного пакета, который я использовал в качестве основы .
Однако, когда я на самом деле запускаю этот пакетный код (например, через построитель запросов fiddler), обновленный с использованием моих собственных путей к сущностям, я получаю следующую ошибку:
Ошибка обработки пакетного запроса. На
начало каждой операции, ровно два
Заголовки должны быть указаны:
«Тип контента» и
'Content-Transfer-Encoding'. Удостовериться
эти заголовки присутствуют и имеют
правильные значения.
Если я удаляю Content-ID из набора изменений, набор изменений работает правильно, но, очевидно, более поздние операции больше не работают, поскольку они ссылаются на этот Content-ID.
Я попытался переместить заголовок Content-ID из заголовка части запроса на изменение, состоящего из нескольких частей .., и в фактические заголовки запроса полезной нагрузки части, то есть:
--changeset(77162fcd-b8da-41ac-a9f8-9357efbbd621)
Content-Type: application/http
Content-Transfer-Encoding: binary
Content-ID: 1
POST /service.svc/Customers HTTP/1.1
Host: host
Content-Type: application/atom+xml;type=entry
Content-Length: ###
<AtomPub representation of a new Customer>
становится
--changeset(77162fcd-b8da-41ac-a9f8-9357efbbd621)
Content-Type: application/http
Content-Transfer-Encoding: binary
POST /service.svc/Customers HTTP/1.1
Host: host
Content-Type: application/atom+xml;type=entry
Content-Length: ###
Content-ID: 1
Опять же, это больше не жалуется на набор изменений, имеющий только заголовки, но все же более поздняя ссылка на идентификатор контента не работает с
HTTP 404, Ресурс не найден для сегмента '$ 1'
Часть запроса, которая ссылается на этот идентификатор контента, выглядит примерно так:
--changeset_7448d3fc-39f6-49bb-b822-30fa4a1676ce
Content-Type: application/http
Content-Transfer-Encoding: binary
POST http://example.org/test.svc/$1/$links/Resources HTTP/1.1
Content-Type: application/json
.. json ..
Предположим, что http://example.org/test.svc является корнем службы.
Документация на самом деле не очень понятна относительно формата местоположений внутреннего запроса, поэтому ссылка на путь может быть неправильной.
Надеюсь, кто-то лучше понял этот аспект и может посоветовать, заранее спасибо.
Стивен.