Există un standard pe JSON denumire? Vad multe exemple folosind toate litere mici separate prin liniuță de subliniere (lower_case). Dar, poți folosi PascalCase sau camelCase?
În acest document Google JSON Ghid de Stil (recomandări pentru construirea JSON Api-uri de la Google),
Se recomandă ca:
Nume de proprietăți trebuie să fie camelCased, siruri de caractere ASCII.
Primul caracter trebuie să fie o literă, un caracter de subliniere (_) sau semnul dolar ($).
Exemplu:
{
"thisPropertyIsAnIdentifier": "identifier value"
}
Echipa mea urmează această convenție.
Nu există nici un standard UNIC, dar am vazut 3 stiluri ai spus ("Pascal/Microsoft", "Java" (camelCase
) și "C" (subliniere, "snake_case"
)) -, precum și cel puțin unul mai mult, pentru kebab-caz " ca " mai-name`).
Cea mai mare parte se pare că depinde de ceea ce de fundal dezvoltatorii de servicii în cauză; cei cu c/c++ de fundal (sau limbi care adoptă aceeași denumire, care include mai multe limbaje de scripting, ruby etc) de multe ori alege subliniere variantă; și restul în mod similar (Java vs .NET). Jackson bibliotecă ce a fost menționat, de exemplu, presupune Java bean convenție de denumire (camelCase
)
UPDATE: definiția mea "standard" este o SINGURĂ convenție. Deci, în timp ce unul ar putea pretinde "da, există mai multe standarde", pentru mine există mai multe Convenții de Numire, nimic din ceea ce este "" standard de ansamblu. Una dintre ele ar putea fi considerat standard pentru platformă specifică, dar având în vedere că JSON este folosit pentru interoperabilitatea între platforme, care pot sau nu pot face prea mult sens.
Acolo este no denumire standard de chei în JSON.
Impunerea unei JSON convenție de denumire este foarte confuz. Cu toate acestea, acest lucru poate fi ușor dat seama dacă se descompun în componente.
"snake_case" încă va face sens pentru cei cu Java intrările din cauza existente JSON biblioteci pentru Java sunt folosind doar metode de a accesa cheile în loc de utilizarea standard dot.sintaxă. Acest lucru înseamnă că nu ar't rănit atât de mult pentru Java pentru a accesa snake_cased cheile în comparație cu celelalte limbaj de programare care pot face dot.sintaxă.
Exemplu pentru Java's org.json
pachet
JsonObject.getString("snake_cased_key")
Exemplu pentru Java's com.google.gson
pachet
JsonElement.getAsString("snake_cased_key")
Alegerea dreptul de JSON convenție de denumire pentru JSON depinde de tehnologia de stivă. Există cazuri în care se poate folosi "snake_case", camelCase, sau orice altă convenție de denumire.
Un alt lucru să ia în considerare este greutatea de a fi pus pe JSON-generator vs JSON parser și/sau front-end JavaScript. În general, mai mult în greutate ar trebui să fie pus pe JSON-generator de partea mai degrabă decât JSON parser parte. Acest lucru este pentru că logica de afaceri, de obicei, se află pe JSON-generator parte.
De asemenea, dacă JSON parser parte este necunoscut, atunci aveți posibilitatea să declare tot ceea ce pot lucra pentru tine.
În special pentru mine pe NodeJS, dacă am'm de lucru cu baze de date și câmpul meu nume sunt subliniere separat, am, de asemenea, să le utilizeze în struct chei.
Acest lucru este din cauza db domenii au o mulțime de acronime/abrevieri deci ceva de genul appSNSInterfaceRRTest se pare un pic murdar, dar app_sns_interface_rr_test este mai frumos.
În variabile Javascript sunt toate camelCase și numele clasei (constructori) sunt ProperCase, deci'd vedea ceva de genul
var devTask = {
task_id: 120,
store_id: 2118,
task_name: 'generalLedger'
};
sau
generalLedgerTask = new GeneralLedgerTask( devTask );
Și, desigur, în JSON chei/siruri de caractere sunt plasate între ghilimele, dar apoi, utilizați doar JSON.stringify și să treacă în obiecte JS, deci don't nevoie să vă faceți griji despre asta.
M-am chinuit un pic pana am gasit acest mediu fericit între JSON și JS convențiile de denumire.
Se pare că nu's destul de variație că oamenii ies din modul lor de a permite conversia de la toate convențiile de la alții: http://www.cowtowncoder.com/blog/archives/cat_json.html
În special, a menționat Jackson JSON parser preferă bean_naming
.
Cred că nu e't un oficial convenție de denumire pentru a JSON, dar puteți urmări unii lideri din industrie pentru a vedea cum se lucrează.
Google, care este una dintre cele mai mari companii IT din lume, are un JSON ghid de stil: https://google.github.io/styleguide/jsoncstyleguide.xml
Profitând, puteți găsi alte stiluri de ghid, pe care Google le definește, aici: https://github.com/google/styleguide
Cum alții au declarat că nu există niciun standard, astfel încât ar trebui să alegeți una singură. Aici sunt câteva lucruri să ia în considerare atunci când se procedează astfel:
Dacă sunteți folosind JavaScript pentru a consuma JSON apoi folosind aceeași convenție de denumire pentru proprietăți în ambele vor oferi consistența vizuală și, eventual, unele oportunități pentru cod curat de re-utilizare.
Un mic motiv pentru a evita kebab-cauza este că cratime poate clash vizual cu " - " personajele care apar în valori.
{ "banca-soldul": -10 }