Percorso della struttura corretto per le risorse API di resto

Question

Percorso della struttura corretto per le risorse API di resto

#1 da (3 voti)

3

Sto strutturando le nostre risorse API rimanenti e ho attraversato un interessante dilemma. Ecco lo scenario e userò un'analogia dell'automobile

/cars/1/
{
   "id": 1,
   "make": "Toyota",
   "year_build": 2015
...
}

/cars/models/1/insurances
{
   "id": 1,
   insurances: [
{
   "policy_number": 101,
   "company": "Insurance Company 1",
   "valid_until": "2015-01-01"
},
{
   "policy_number": 102,
   "company": "Insurance Company 2",
   "valid_until": "2016-01-01"
}
]
...
}

Ho notato che le risorse possono essere raggiunte con entrambi i / cars / 1 / assicurazioni / 102 e / cars / 1 / assicurazioni? policyid = 102 , ma / cars / 1 / assicurazioni / 102 è più pratico se vogliamo utilizzare ulteriori risorse come / cars / 1 / assicurazioni / 102 / agenti / ....

La mia domanda è davvero che devo seguire il percorso completo dell'URL se ogni politica ha un numero univoco, ad esempio potrei usare

/ cars / assicurazioni / 102

per ottenere questo criterio anziché

/ vetture / 1 / assicurazioni? PolicyId = 102

Prenderebbe una polizza una risorsa primaria invece di una macchina?

rest

posta John 05.04.2017 - 19:33

fonte

1 risposta

Leggi altre domande sui tag rest

È una buona idea che un'API restituisca solo gli ID dagli oggetti? Come si restringono classi specifiche per una proprietà?

score 3 · Accepted Answer

REST non si cura di quale ortografia usi per i tuoi identificatori - sono opachi, dal punto di vista del cliente, quindi il server può fare tutto ciò che vuole.

Ci sono convenzioni in gioco per la progettazione dell'URI per renderle più facilmente comprensibili da quelle umane. Vedi Progettazione di un'API REST in base all'URI e alla stringa di query .

My question really is do I have to follow the full path of url if each policy has a unique number

Se le policy sono entità univoche nel modello, la modellazione di ciascuna di esse come elemento nell'insieme di criteri è una cosa ragionevole da fare: /policies/104

È normale, in REST, avere più URI (quindi più risorse) che condividono la stessa rappresentazione. Ad esempio, potrebbe esserci un modulo che dice "inserisci il tuo numero di polizza" che, quando inviato, va a /policies?policyNumber=105 che potrebbe quindi reindirizza l'utente a qualche altra risorsa /policies/105 o potrebbe presentare il contenuto dell'altra risorsa (tramite Content-Location ) o potrebbe presentare una propria rappresentazione (che potrebbe duplicare le rappresentazioni di altre risorse).

URIs do NOT map onto domain objects - that violates encapsulation.... You should expect to have many many more resources in your integration domain than you do business objects in your business domain. --Jim Webber, 2011.

Si noti che in REST, l'aspettativa è che i client stiano negoziando i propri protocolli seguendo i link ipermediali . Se non stai dando ai clienti link da seguire, ma invece stai facendo in modo che i clienti indovinino il prossimo URL, allora dovresti dare la priorità usando un insieme di ortografie coerenti e facili da ricordare.

Sì, in particolare quando è naturale pensare in termini di sottorisorse, è più comodo che l'identificatore sia contenuto all'interno di hier-part dell'URI.