Che cos'è una buona convenzione REST per la struttura di una risposta che è solo un contenitore di due (o più) entità indipendenti

1

Diciamo che ho le seguenti entità a cui è possibile accedere ai seguenti URI (usando la pluralizzazione standard):

/things/:id e /otherthings/:id

Voglio esporre per motivi di prestazioni, una API che risponderà con la seguente struttura:

{
   "things": [],
   "otherthings": []
}

La chiamata è così che i miei clienti possono recuperare tutte le entità in una singola chiamata, invece di effettuare due chiamate separate a /things e /otherthings .

La mia domanda
Avrebbe senso avvolgere questo in una chiamata a /thingscontainer o qualcosa e considerarla una nuova entità? Voglio solo esporre un GET per la chiamata per ottenere il "contenitore" con entrambe le raccolte e tutte le ulteriori interazioni con le entità o le raccolte di entità stesse colpiranno i loro endpoint "cose" appropriati.

L'approccio all'oggetto "contenitore" che sto descrivendo sembra che potrebbe non essere molto RESTful. Sto bene con questo, ma vorrei qualche idea su come evitare di deviare da esso se possibile.

    
posta Ryan Weir 05.10.2016 - 17:06
fonte

1 risposta

2

Sì, va bene. Quello che stai facendo in realtà è creare una nuova risorsa: contenitore di cose. Il nome è un po 'vago però. Principalmente perché è molto astratto.

Un po 'più linguaggio umano:

/ allthings

{
  bigThings: [],
  smallThing: []
}

Un esempio più concreto potrebbe essere la ricerca:

/ searchresults / {searchId}

{
  websites: [],
  documents: []
}

Penso che l'ultimo esempio sia davvero chiaro e non ci sia assolutamente nulla di non-REST in esso.

    
risposta data 05.10.2016 - 17:25
fonte

Leggi altre domande sui tag