È una cattiva pratica usare i trattini nelle chiavi JSON?

Vedo molte domande che ruotano intorno all'accesso alle chiavi JSON che usano trattini (caso kebab), ma ora mi chiedo se dovrei semplicemente attenermi a camelCase o snake_case nelle mie chiavi. So che anche i trattini possono creare mappature complicate quando vengono trasferiti tra le lingue. Ho visto alcune librerie deserializzare JSON convertire quelle chiavi in uno stile camelCase.

Esempio:

var something = {
  "some-value": 'thing'
}

var something = {
  "someValue": 'thing',
  "some_other_value": 'thing_two'
}

— Matt Oaxaca
fonte

REST non ha nulla da dire sui formati di payload.

— Eric Stein,

Perché usi il caso kebab in JSON? Le persone di solito usano camelCase per JSON perché è sempre buona norma seguire le convenzioni di denominazione dell'ambiente di programmazione ed è pratica standard usare camelCase per variabili in JavaScript. Anche se suppongo che stai usando JSON per comunicare con JavaScript.

— Alternatex,

Vedo che la domanda è taggata con JavaScript, ma la domanda stessa sembra riguardare un'API tra lingue / librerie diverse. Se sei interessato a javascript, nota che la notazione punto non funziona con i trattini.

— Izkata,

Non è davvero una cattiva pratica, poiché JSON è indipendente dalla lingua e quindi non dovrebbe essere vincolato dalla sintassi di una determinata lingua. Detto questo, ha senso usare solo caratteri alfanumerici, dal momento che questo può mappare direttamente agli identificatori in tutti i linguaggi tradizionali, quindi questo porterà solo alla minima quantità di problemi di mappatura.

— Jacques B,

@Alternatex: +1 per "caso kebab" :-)

— gnasher729,

Risposte:

È possibile utilizzare qualsiasi cosa come chiavi JSON, purché sia UTF-8 valido, non contenga zero punti di codice e sarebbe utile se si potesse rappresentare la chiave come stringa nel linguaggio di programmazione di propria scelta. Potrei raccomandare di non usare diverse rappresentazioni Unicode della stessa stringa (ad esempio "Ä" scritto come uno o due punti di codice).

Leggere alcuni commenti: sembra che alcune persone provino a creare classi con variabili di istanza che corrispondono alle chiavi nei dizionari JSON. Che ovviamente non funziona se la tua chiave è "un po 'di valore" a meno che tu non scriva COBOL. Penso che sia sbagliato. Ho delle classi modello che sono progettate nel modo in cui le voglio. JSON viene utilizzato solo per riempire le classi del modello. Prenderò qualunque cosa i ragazzi del server abbiano deciso di utilizzare per le chiavi e lo inserirò negli oggetti del mio modello.

— gnasher729
fonte

urgentemente, poni la domanda su come il tuo programma di consumo accede alle chiavi json. Comunemente questo viene fatto analizzando il json come oggetto. L'uso di ipotesi o altri personaggi che impediscono ciò rende la vita difficile ai tuoi consumatori

— Ewan,

E questo è valido: {"❓": "✅"}

— Vinicius Brasil,

In che modo i trattini impediscono qualsiasi cosa? Ricevo un dizionario e posso usare "un po 'di chiave" come chiave, posso anche usare "❓" come chiave.

— gnasher729,

Esistono molti sistemi di serializzazione JSON che sono più che in grado di gestire la mappatura tra nomi di campi che non sono adatti per l'uso nella lingua con cui si integrano. Nella maggior parte dei casi, non sono difficili da usare e richiedono solo un piccolo sforzo extra. In un mondo ideale, non dovresti, ma se la tua API utilizza già trattini, cambiarlo sarebbe una cura peggiore della malattia. Nota anche che l'uso di trattini è lo stile più comune in alcune lingue, in particolare quelli basati su LISP, quindi probabilmente c'è una minoranza silenziosa dei consumatori delle tue API che sono felici di vedere trattini piuttosto che un altro formato.

— Jules
fonte

Voterò al più presto e ho trovato informazioni, grazie.

— Matt Oaxaca,

Dopo aver trascorso un po 'di tempo nel settore e aver lavorato su alcuni sistemi. Non penso che ci sia una buona pratica o un involucro adeguato per le chiavi JSON. L'aspetto più importante di qualsiasi formattazione (involucro / stile di codice / ecc.) È la coerenza e l'adozione del team.

Se la base di codice è frammentata e incoerente, incontrarsi come una squadra e concordare uno stile coerente, quindi sorvegliare la formulazione collettivamente.

— Matt Oaxaca
fonte