Restituisce sempre singoli oggetti in un array per i payload JSON dell'API REST?

Naviga le tue risposte
8

Per un'API REST a cui sto lavorando, voglio restituire JSON in un layout coerente: 

{
  "Data" : {
     "Id" : 123,
     "Email" : "[email protected]"
     "Firstname" : "Charlie",
     "Surname" : "Brown",
 },
 "Error" : null
}

Il payload conterrà sempre "Dati" e "Errore", dove uno o l'altro può essere nullo.

La mia domanda si riferisce a "Dati" e endpoint che restituiscono sempre e solo un oggetto. Ad esempio, supponiamo di avere un'API users/current , che restituisce l'utente attualmente autenticato. Avrei restituito quell'utente come mostrato sopra; un singolo oggetto JSON denominato "Dati".

Per gli endpoint che potrebbero restituire zero, uno o più oggetti, allora vorrei (ovviamente) rendere "Dati" come un array: 

{
  "Data" : [
    {
      (first object)
    },
    {
      (second object)
    }
  ],
  "Error" : null
}

Ho sentito un punto di vista che, per coerenza, "Data" dovrebbe sempre essere un array. Anche quando un endpoint restituirebbe sempre e solo in modo logico un singolo oggetto (o null).

Che cosa pensano gli altri? Penso che non sia necessario creare "Dati" e array se non ci sarà mai più di un oggetto restituito.

    
posta Diego Barros 20.04.2012 - 05:28
fonte

4 risposte

9

Penso che questo tipo di coerenza sia fuorviata.

È improbabile che avvolgere i dati in un array avvantaggino un utente API, poiché dovrebbe comunque sapere come interpretare i dati effettivi. Ad esempio, è improbabile che i risultati "dati" di /users/current e /cities/chicago/restaurants vengano gestiti dallo stesso codice.

Per gli errori, d'altra parte, è probabile che tutti gli errori siano elaborati dallo stesso codice di gestione degli errori, e quindi c'è un vantaggio nell'usare la stessa struttura.

Chiediti: se questa era una classe nella tua lingua OOP preferita, faresti tutti i metodi per restituire lo stesso tipo per coerenza?

    
risposta data 20.04.2012 - 06:33
fonte
1

Se il destinatario ha bisogno di un destinatario generale per i messaggi JSON, può essere utile avere il nodo dati dello stesso formato. Quindi in questo caso è utile avere sempre un array, quindi può essere analizzato nello stesso modo ogni volta.

Se ciascuna risposta verrà gestita individualmente (chiamate API diverse da metodi diversi), posso vedere il tuo punto, tuttavia dovrebbe essere assolutamente chiaro (dalle chiamate API) quando un array o un oggetto deve essere restituito.

    
risposta data 20.04.2012 - 06:04
fonte
0

Non sono un fan dell'approccio alla matrice perché non offre una vera coerenza. Forza l'utente del servizio a interrogarsi su cose come, cosa succede se c'è più di un oggetto in questo array o per liberarsi dell'array wrapping il prima possibile per quegli array singleton. Dovresti ancora fare due cose diverse.

Tuttavia, se si utilizza l'array, assicurarsi che Data non sia mai nullo. Se non ci sono dati, la matrice dovrebbe essere vuota. È l'unico vantaggio che riesco a vedere.

    
risposta data 20.04.2012 - 06:52
fonte
-1

Sto cadendo dalla parte di sempre restituendo un array. Dal lato del cliente, utilizzo il mio oggetto di risposta "Utenti" sia che ottenga tutti gli utenti sia solo uno. Se si dispone di un endpoint che restituisce matrici e un altro che restituisce lo stesso oggetto, ma mai più di uno, utilizza ancora un array.

Ci sono argomenti simili per usare la stessa logica sul lato server, basta usare lo stesso codice se la tua query restituisce un oggetto o più.

L'unica eccezione potrebbe essere quando si restituisce un oggetto che non esiste mai come array, in qualsiasi contesto, quindi non ce n'è bisogno.

    
risposta data 20.04.2012 - 06:30
fonte

Leggi altre domande sui tag

Sorgente di eventi, un evento, lo stato di due aggregati è cambiato Il sourcing degli eventi è pronto per la prima serata? [chiuso]