Se dovessi provare a descrivere quali sono tutti i campi dell'oggetto che potresti essere , lo troverai difficile con l'approccio di:
{
"id1": { ... },
"id2": { ... }
}
Questo perché l'insieme di tutti gli ID possibili è difficile da descrivere.
D'altra parte, tornare indietro di un elenco di oggetti di un tipo noto è qualcosa che può essere descritto bene.
Per documentare gli endpoint REST, sono un fan di swagger e della sua struttura. In questo caso, la / pet / findByStatus chiamata è uno di questi esempi.
/pet/findByStatus:
get:
parameters:
- name: status
in: query
required: true
type: array
items:
type: string
enum:
- available
- pending
- sold
default: available
collectionFormat: multi
responses:
'200':
description: successful operation
schema:
type: array
items:
$ref: '#/definitions/Pet'
E la definizione per l'oggetto Pet
:
Pet:
type: object
required:
- name
- photoUrls
properties:
id:
type: integer
format: int64
...
Da questo si può vedere che la struttura che si otterrà è quella di un elenco di oggetti ben definito.
È molto più facile dire a un cliente che otterrà un elenco di oggetti che riempie questa struttura piuttosto che descrivere i possibili campi che un oggetto potrebbe restituire.
L'eccezione qui è che se questa lista di id è ben nota in anticipo e immutabile. Che hai tre campi per red
, green
e blue
e sempre non hai più quei campi, allora la struttura dell'oggetto potrebbe essere una scelta migliore.
Tuttavia, con gli esempi forniti - si sta restituendo un oggetto elenco e quindi una struttura di tipo elenco è un'opzione migliore per comunicare in modo chiaro l'intento del codice. Iterando sopra la lista li avrai tutti - e nell'ordine definito. Non devi preoccuparti di un ordine che cambia per una struttura hash / mappa / dizionario sul client. Non devi forzare il cliente a percorrere questa struttura potenzialmente inefficiente.