Как обрабатывать сложные отношения при создании API-интерфейса odata?

Question

Я создаю веб-API Asp.Net для стороннего продукта и рассматриваю использование OData 4 для моего API. У меня есть достаточная свобода в моей объектной модели, но я не могу изменить базовую модель данных.

Я понимаю, что odata поддерживает свойства навигации для определения отношений, но они, по-видимому, являются прямыми связями между объектами. Во многих случаях в модели данных, на которой я строил отношения, есть свои собственные свойства. Например, «Пользователь» имеет коллекцию отношений «Член» с группами, организационными единицами и т. Д., А сама ссылка «Member Of» имеет свойство «По умолчанию» boolean. В некоторых случаях отношения имеют несколько свойств.

Есть ли лучший способ справиться с этим? Должен ли я создать объект «Членство» со свойствами и иметь два прыжка от пользователя с навигационными свойствами (User> Membership> Group)? Должен ли я создать сложный тип «Членство», создайте свойство «Членство», которое представляет собой коллекцию «Членство» и имеет свойство навигации в «Членстве» (если это возможно)? С помощью любой из этих опций я должен также добавить свойство навигации только для чтения для всех участников групп (User> Group)?

Благодаря

Answer 1

С точки зрения REST (см Richardson Maturity Model level 3), один раз навигации к user ресурсу, клиент может обнаружить group-query связь (ссылка). Вот как это может выглядеть в инструменте, как HAL Browser:

"api:group-query": { 
    "href": "http://apiname:port/api/group?userId=1,pageNumber={pageNumber}&pageSize={pageSize}&sort={sort}" 
}, 

Это бы потребителя к (постраничный) сбор group ресурсов, которые пользователь является членом:

GET /api/user/1/groups

который может вернуть что-то вроде этого:

{ 
    "groups": [ 
     { 
     "id": 123, 
     "name": "Test Group" 
     }, 
     { 
     "id": 134, 
     "name": "Tennis squad" 
     } 
    ] 
} 

Я не вижу никакой необходимости в membership ресурсов/entit y, если вы интегрируете ссылки.