Restituisce un oggetto json invece un array tramite lo stile REST buono o cattivo?

1

Sto lavorando sulla mia API e vorrei restituire alcune statistiche. Questi sono memorizzati e raccolti in codice, e posso scegliere il mio modo di restituirli.

Il mio primo approccio era l'uso dell'hash, quindi i miei dati assomigliano a:

{
    'obj1': { 'in': 23, 'out': 22},
    'obj2': { 'in': 33, 'out': 19}
}

Questo stile è accettabile o dovrei usare meglio:

[
    { 'identifier': 'obj1', 'in': 23, 'out': 22},
    { 'identifier': 'obj2', 'in': 33, 'out': 19}
]

Mi piace lo stile 2, perché mi fornisce una base, quando posso effettivamente testare il tipo di risultato per ciascuno dei valori (come 'obj1' e numeri).

Esiste una soluzione di best practice REST, dove posso leggere di più su questo?

    
posta Vestel 04.03.2016 - 13:13
fonte

3 risposte

5

Domande come queste sono difficili da rispondere, perché sono per lo più basate sull'opinione pubblica. Ti consiglio di mettere entrambe le soluzioni su carta e di pensare ai loro casi d'uso in futuro, persino di testarle. Quale è più facile da gestire, che è più facile da regolare e che ti offre più opzioni se è necessario aggiungere o rimuovere una funzionalità.

    
risposta data 04.03.2016 - 13:20
fonte
1

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.

    
risposta data 06.03.2016 - 03:32
fonte
0

Non basato su opinioni, ma a seconda della situazione. Il primo è un dizionario (non ordinato, ricerca rapida per chiave), il secondo è un array (ordinato, elaborazione sequenziale veloce, ricerca per chiave lenta).

Di cosa ha bisogno il cliente? E l'identificatore è una parte dell'oggetto, o solo una chiave per identificarlo? Se è una parte dell'oggetto, dovrebbe essere inclusa nel dizionario per ogni oggetto.

    
risposta data 04.03.2016 - 16:09
fonte

Leggi altre domande sui tag