odata API를 작성할 때 복잡한 관계를 처리하는 방법은 무엇입니까?

Question

제 3 자 제품 용 Asp.Net 웹 API를 구축 중이며 API에 OData 4 사용을 고려하고 있습니다. 내 개체 모델에 상당한 자유가 있지만 기본 데이터 모델을 변경할 수는 없습니다.

odata는 관계를 정의하기위한 탐색 속성을 지원하지만 객체 간의 직접 링크 인 것처럼 보입니다. 많은 경우에 관계를 구축하고있는 데이터 모델에는 자체 속성이 있습니다. 예를 들어, '사용자'는 그룹, 조직 단위 등과의 '소속 그룹'의 소속 목록을 가지고 있으며 '소속 그룹'링크 자체는 '기본값 임'부울 속성을가집니다. 경우에 따라 관계에는 여러 속성이 있습니다.

이 문제를 해결하는 가장 좋은 방법이 있습니까? 속성이있는 '멤버쉽'엔티티를 만들고 네비게이션 속성이있는 사용자 (사용자> 멤버쉽> 그룹)에서 두 개의 홉을 가져야합니까? 'Membership'복잡한 유형을 만들어야 만 'Membership'의 컬렉션 인 'Memberships'속성을 만들고 'Membership'에 네비게이션 속성 (가능한 경우)이 있습니까? 이러한 옵션 중 하나를 사용하여 편의를 위해 그룹의 모든 구성원에게 읽기 전용 탐색 속성을 추가해야합니까 (사용자> 그룹)?

감사

지내는 관점합니다 ( Richardson Maturity Model level 3 참조)에서

Answer 1

는 한 번 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 리소스/자격이 필요하지 않습니다. y 링크를 통합하는 경우.