2014-11-08 15 views
6

Załóżmy, że mam model User i UserType. Chciałbym dodać odniesienie do UserType-ID w modelu użytkownika. Dokumentacja typu "swagger" pokazuje jedynie jak odwoływać się do innego (całego) modelu, a nie tylko do jednej z jego właściwości.Sposób odwoływania się do identyfikatora innej definicji modelu w Swagger

Tak więc zastanawiałem się, czy możliwe jest odniesienie tylko do właściwości innej definicji modelu.

"definitions": { 
    "User": { 
     "required": [ 
      "username", 
      "typeId" 
     ], 
     "properties": { 
      "id": { 
       "type": "integer", 
       "format": "int32" 
      }, 
      "username": { 
       "type": "string" 
      }, 
      "typeId": { 
       "$ref": "UserType.id" // ==> this doesn't work! and without 
             // the ".id" part it would include all 
             // the properties of UserType 
      } 
     } 
    }, 
    "UserType": { 
     "required": [ 
      "name" 
     ], 
     "properties": { 
      "id": { 
       "type": "integer", 
       "format": "int32" 
      }, 
      "name": { 
       "type": "string" 
      } 
     } 
    } 
} 

Albo jest to, że w ogóle nie jest możliwe i powinno być zawsze tylko:

"definitions": { 
    "User": { 
     ... 
     "properties": { 
      "typeId": { 
       "type": "integer", 
       "format": "int32" 
      } 
     } 
    }, 
    ... 
} 
+0

Zanim przejdę do odpowiedzi, dlaczego chcesz odwołać się do * pierwotnej * definicji? Co to oszczędza na piśmie? – Ron

+0

Sądzę, że myślę, że każdemu, kto czyta dokumentację REST, byłoby bardziej przejrzyste, aby zobaczyć "połączony" model. – roberkules

+0

I w przypadku, gdy musiałbym zmienić typ UserType.id, nie musiałbym aktualizować wszystkich odniesień. – roberkules

Odpowiedz

6

W Swagger 2.0, Schemat Obiekty nie konieczne opisać modele (w przeciwieństwie do modelu obiektowego w poprzednich wersjach). Na przykład, jeśli spojrzysz na parametry "body", zobaczysz, że musisz zdefiniować Schemat jako typ, ale ten schemat może również reprezentować prymitywy i tablice.

Na powyższe pytanie (i komentarze), polecam stosując następującą strukturę:

"defintions": { 
    "User": { 
    "required": [ 
     "username", 
     "typeId" 
    ], 
    "properties": { 
     "id": { 
     "type": "integer", 
     "format": "int32" 
     }, 
     "username": { 
     "type": "string" 
     }, 
     "typeId": { 
     "$ref": "#/definitions/TypeId" 
     } 
    } 
    }, 
    "UserType": { 
    "required": [ 
     "name" 
    ], 
    "properties": { 
     "id": { 
     "$ref": "#/definitions/TypeId" 
     }, 
     "name": { 
     "type": "string" 
     } 
    } 
    }, 
    "TypeId": { 
    "type": "integer", 
    "format": "int32" 
    } 
} 

TypeId jest teraz externalized i powinien przyjść czas i chcesz zmienić swoją definicję, można zmień go w jednym miejscu. Oczywiście możesz dodać dodatkowe "description" do pól i modeli, aby lepiej udokumentować cel.

+1

Tak, to jest sposób, aby przejść obecnie. Niestety traci niektóre dane, które mogą być przydatne do generowania bazy danych w oparciu o schemat. –

+0

Nic w tym złego. Jest to narzędzie dokumentacji interfejsu API, a nie aplikacja/baza danych. Rzutowanie z reprezentacji API na reprezentację bazy danych jest zazwyczaj bardzo złe. – Ron

+0

czy to nadal jest ważne? – Yerken

Powiązane problemy