Как обновить сущность OData и изменить ее свойства навигации в одном запросе?

Я пытаюсь реализовать простой сценарий, используя службу OData, предоставляемую службами данных WCF (используя приложение OData V3 / json; на данный момент odata = подробный формат полезной нагрузки. Я могу использовать формат JSON Light в будущем) , Основной сценарий выглядит так:

У меня есть две сущности:

class Person 
{ 
  public int ID { get; set; }
  public string Name { get; set; } 
  public virtual PersonCategory Category { get; set; }
}

class PersonCategory
{
  public int ID { get; set; }
  public string Description { get; set; }
  public virtual ICollection<Person> People { get; set; }
}

Теперь я хочу создать простую страницу редактирования для Персона. Эта страница редактирования может иметь ввод для имени и ввод или раскрывающийся список для категории человека.

Итак, сценарий идет:

Code downloads the Person using $expand for the Category: GET /api.svc/People(1)?$expand=Category User edits both the person's Name property and their Category. Code for the page makes a single request to update that Person's Name and Category properties.

Ключ здесь находится в «одном запросе». Это та часть, для которой у меня проблемы с поиском документации. Я видел примеры, где они делят число 3 выше на два запроса. Примерно так (я не помню точный формат - я также не уверен, нужно ли вам УДАЛИТЬ ссылку на категорию перед выполнением PUT):

PATCH /api.svc/People(1) with content: {"Name": "new name" }
PUT /api.svc/People(1)/$links/Category with content: { "url": "/api.svc/Categories(2)" }

Но я также слышал, что он сказал, но не продемонстрировал, что возможно реализовать это обновление в виде одного запроса с изменением свойства навигации Category, заданным в соответствии с другими изменениями в сущности Person. Может ли кто-нибудь дать мне пример того, как это можно сделать? Кроме того, не могли бы вы показать мне, как это будет сделано с помощью свойства навигации «многие ко многим», в отличие от описанного выше метода «один ко многим».

И, наконец, я в настоящее время использую подробный формат JSON, V3. Если бы я использовал новый формат JSON light, ваши ответы на вышеприведенные вопросы были бы другими? Если так, то как?

Ответы на вопрос(3)

Ваш ответ на вопрос