Det korte svar: JSON er det sikreste valg til dataudveksling mellem maskiner, mens YAML er det sikreste valg til konfiguration, som redigeres manuelt. Det hele koger ned til én designbeslutning: hvor hvert format placerer sin struktur. JSON monterer stilladset på ydersiden i form af klammer og parenteser, som er synlige. YAML gemmer det inde i væggene ved hjælp af whitespace, som ikke er synligt. Begge er dataserialiseringsformater, der udfører det samme stykke arbejde, hvilket er grunden til, at valget ofte træffes af vane frem for bevidst, og hvorfor så mange teams ender med at vedligeholde begge dele. Her er hvordan du vælger.
JSON står for JavaScript Object Notation, og som navnet antyder, stammer det fra JavaScript-dataformater. Det er en åben standard: letvægts, tekstbaseret og med et bevidst begrænset sæt datatyper. Kort syntaks, enkel struktur og meget let at læse.
Det bruges til at sende data til en server og tilbage til klienten, som en konvolut der indeholder data, mens den sendes mellem parter. Programmører bruger det i mobilapps, i dokumentdatabaser som MongoDB (som gemmer et binært, JSON-lignende format kaldet BSON), i beskedkøer og log-pipelines, og i brugerrettede REST-API'er som et mere brugervenligt alternativ til XML. Det er standardformatet for REST-API'er, og alle browsere kan parse det indbygget.
Ifølge JSON's udvikler, Douglas Crockford, var et sprog baseret på de samme principper allerede i brug hos Netscape i 1996, men JSON blev først etableret som en mainstream-syntaks omkring 2001. Det er sproguafhængigt, så det fungerer med ethvert programmeringssprog, og denne portabilitet er hovedårsagen til, at det har spredt sig, som det har.
En .json -fil er en almindelig tekstfil, der indeholder et enkelt JSON-dokument, gemt med .json -endelsen og læsbar i enhver editor. Den bruger en kort liste af datatyper: strenge, tal, objekter, arrays, boolske værdier og null. Syntaksen låner konventioner, som er velkendte for programmører af C-familie-sprogene: C, C++, C#, Java, JavaScript, Perl, Python og resten. Som det officielle JSON-websted formulerer det, er et objekt et uordnet sæt af navn/værdi-par, der starter med en venstre krøllet parentes og slutter med en højre krøllet parentes, hvor hvert navn efterfølges af et kolon, og parrene adskilles af kommaer.
Den fungerende grammatik kan være på den ene side hos json.org: ikke et resumé af specifikationen, men selve specifikationen. Formatet er også formelt standardiseret som ECMA-404 (2. udgave, 2017) og IETF RFC 8259 (2017), men den grammatik, som disse dokumenter fastlægger, er den samme kompakte version. Husk det, når YAML-specifikationen dukker op senere.
De samme data, først i JSON, med information om heavy metal-bandet Metallica:
{
"band": "Metallica",
"formed": 1981,
"origin": "Los Angeles, California",
"genres": ["thrash metal", "heavy metal"],
"active": true,
"members": [
{ "name": "James Hetfield", "role": "vocals, rhythm guitar", "joined": 1981 },
{ "name": "Lars Ulrich", "role": "drums", "joined": 1981 },
{ "name": "Kirk Hammett", "role": "lead guitar", "joined": 1983 },
{ "name": "Robert Trujillo", "role": "bass", "joined": 2003 }
],
"disbanded": null
}Krøllede parenteser afgrænser objektet og arrays; hvert element er sat i anførselstegn; et kolon adskiller hvert navn fra dets værdi, og et komma adskiller det ene par fra det næste. Hele strukturen ligger lige der på ydersiden, hvor du kan tælle den.
Det fungerer, fordi syntaksen er kompakt og læsbar for mennesker, markuppen er minimal, parsing er hurtig i alle sprog, og understøttelsen er stort set universel.
Det kommer til kort på tre punkter. Datatyperne stopper ved strenge, tal, objekter, arrays, boolean og null, så alt mere komplekst skal kodes som en streng og dekodes manuelt i den anden ende. Der er ingen understøttelse af navnerum, kommentarer eller attributter, og de manglende kommentarer er noget, man savner i en konfigurationsfil. Og strukturen er bevidst enkel, så kompleks konfiguration har tendens til at udvikle konventioner ovenpå.
YAML stod tidligere for Yet Another Markup Language, indtil betydningen blev ændret til YAML Ain't Markup Language for at lægge vægt på data frem for dokumenter. Det er et meget letlæseligt og letvægtsformat, der oftest bruges til at gemme konfigurationer til DevOps-værktøjer som Elasticsearch, Docker, Kubernetes, Prometheus og Ansible.
Som det officielle websted, der selv er skrevet i YAML, formulerer det, er YAML et menneskevenligt dataserialiseringssprog til alle programmeringssprog. Det er et dataserialiseringssprog, selvom det lige så ofte bruges til konfigurationsfiler. Vi vil se på det gennem dataserialiserings-prismet.
YAML blev første gang offentliggjort i 2001. Grundlæggerne er Ingy dot Net, Clark Evans og Oren Ben-Kiki, som gik sammen om at skabe noget, der var enklere end XML. Siden da er det blevet standardformatet for konfiguration på tværs af det meste af DevOps-værktøjskæden, hvilket betyder, at valget ofte er truffet for dig, før du overhovedet starter.
En YAML-fil er en almindelig tekstfil, der gemmes som .yaml eller .yml, og som indeholder et eller flere YAML-dokumenter. Én fil kan indeholde flere dokumenter adskilt af en linje med tre bindestreger, hvilket er måden, hvorpå et Kubernetes-manifest samler et deployment og en service. Det understøtter kommentarer, og det alene gør det behageligt at redigere.
YAML er et supersæt af JSON: ethvert gyldigt JSON-dokument er også gyldig YAML, så en YAML-fil kan indeholde JSON-objekter, og en YAML-parser læser en .json fil uændret. Det håndterer komplekse datatyper uden problemer og indlejrer objekter så dybt, som du har brug for. Den samme fleksibilitet er grunden til, at nogle systemer begrænser, hvilke YAML-funktioner de accepterer.
#).|) bevarer linjeskift, mens større-end-tegnet (>) samler dem til én linje.De samme data igen, nu i YAML:
band: Metallica
formed: 1981
origin: Los Angeles, California
genres:
- thrash metal
- heavy metal
active: true
members:
- name: James Hetfield
role: vocals, rhythm guitar
joined: 1981
- name: Lars Ulrich
role: drums
joined: 1981
- name: Kirk Hammett
role: lead guitar
joined: 1983
- name: Robert Trujillo
role: bass
joined: 2003
disbanded: nullTre forskelle springer i øjnene. Krøllede parenteser og klammer er væk, og indrykning angiver hierarkiet. Anførselstegnene er også væk, fordi YAML udleder typen fra værdien. Og medlemmerne er en sekvens af bindestreger frem for et kommasepareret array, så tilføjelse af et femte element er en ny blok frem for en redigering af tegnsætningen omkring det.
Mere ryddeligt, ja. Men se nærmere på, hvor stilladset blev af. I JSON-versionen er det eksplicit angivet. I YAML-versionen udledes det af blanktegn, hvilket er et meget anderledes løfte.
Det fungerer, fordi syntaksen er letlæselig, indrykning angiver struktur uden tegnsætning, kommentarer understøttes, komplekse strukturer kan udtrykkes, og ankre gør det muligt at genbruge en blok frem for at kopiere den. Dette genbrug er en af grundene til, at YAML beskriver infrastruktur, for eksempel Kubernetes-stacks, hvor de samme indstillinger går igen på tværs af dusinvis af objekter.
Det kommer til kort præcis der, hvor fleksibiliteten findes. Forkert indrykning eller mellemrum skaber valideringsfejl, eller endnu værre, en fil der bliver fortolket som noget, du ikke havde til hensigt. Dens deklarative natur gør fejlfinding sværere: der er intet at gennemgå trin for trin, så fejlen dukker først op, når filen bliver læst eller anvendt. Og typeinferens har sine fælder, hvor den mest kendte er landekoden for Norge, NO, som læses som den boolske værdi false, medmindre du sætter den i anførselstegn. Strengt taget hører den opførsel til YAML 1.1: den nuværende specifikation, YAML 1.2, revision 1.2.2 (oktober 2021), begrænser boolske værdier til kun at være true og false. Fælden eksisterer stadig i praksis, fordi rigtig mange parsere stadig bruger 1.1-semantik som standard, så i praksis sætter man NO i anførselstegn og kommer videre.
YAML og JSON er to populære formater, der minder om hinanden i struktur og anvendelighed. Deres forskelle i design, syntaks og funktionalitet gør, at valget mellem dem afhænger af formålet.
| Funktion | JSON | YAML |
|---|---|---|
| Syntaks | Tuborgklammer, kantede klammer, citationstegn og kommaer | Indrykning, kolonner og bindestreger |
| Kommentarer | Ikke understøttet | Understøttet med # |
| Datatyper | Strenge, tal, objekter, arrays, sandhedsværdier, null | De samme, samt datoer og tidsstempler |
| Fortolkningshastighed | Hurtigere: en lille, entydig grammatik | Langsommere: en langt større specifikation |
| Menneskelig læsbarhed | God, når man først ser bort fra tegnsætningen | Bedre til manuel redigering, sværere til at overskue struktur |
| Genanvendelse | Ingen | Ankres og aliaser |
| Værktøjssupport | Indbygget i browsere og næsten alle standardbiblioteker | Kræver et eksternt bibliotek i de fleste sprog |
| Typisk anvendelse | API'er, dataudveksling, maskingenererede filer | Konfigurationsfiler, CI-pipeliner, infrastruktur |
En grundlæggende forskel ligger bag det hele. JSON er designet til, at maskiner kan skrive og læse det, så det definerer sin struktur præcist og efterlader ingen plads til fejlfortolkning for en parser. YAML er designet til mennesker, så det flytter strukturen over i whitespace, hvilket får filen til at ligne en disposition frem for kode.
Forskellen i parsing stammer fra specifikationerne, ikke fra benchmarks. JSON-grammatikken fylder en enkelt side på json.org. YAML 1.2-specifikationen fylder derimod dusinvis af sider, der dækker anchors, tags, block scalars, flere dokumenter og implicit typning: mere arbejde for parseren og flere måder, hvorpå det kan gå galt. Betragt hastighedsforskellen som en forskel i karakter frem for et tal: irrelevant for en fil, der læses én gang ved opstart, men målbar for en tjeneste, der deserialiserer hele dagen.
Det er også grunden til, at de fejler på forskellige måder. En fejlbehæftet JSON-fil går som regel i stykker med det samme under parsing. En fejlbehæftet YAML-fil parser ofte uden problemer, men betyder noget helt andet, fordi et indryk har flyttet en nøgle under den forkerte forælder, eller en værdi uden anførselstegn er blevet tolket som den forkerte type. Tavse fejl er de dyreste.
Ingen af dem er bedst i teorien. Spørgsmålet giver først mening, når du kender opgaven, så se på funktionen: Hvad skal formatet kunne?
JSON er det bedste valg til dataudveksling. Det er hurtigt at parse, understøttes overalt uden afhængigheder, og hvert element er eksplicit afgrænset, hvilket forhindrer parseren i at misforstå strukturen. Prisen er det begrænsede udvalg af datatyper, så mere komplekse værdier bliver kodet som strenge og afkodet ved udlæsning. Hvis du designer den slags udvekslinger, så sammenligner vi GraphQL vs. REST og vejer de to dominerende API-stile op mod hinanden.
YAML er det bedste valg til konfiguration, som vedligeholdes af mennesker. Det understøtter kommentarer, kan indlejres dybt uden at ophobe tegnsætning, og ankre gør det muligt at skrive fælles indstillinger én gang. Prisen er, at strukturen afhænger af whitespace, så en fil kan være syntaktisk korrekt, men logisk forkert, og parseren har mere arbejde at udføre.
Kort sagt: hvis et program skriver filen, så brug JSON. Hvis et menneske skriver filen, så brug YAML, og sørg for at validere den.
Denne opdeling er ikke abstrakt for os. Da vi flyttede FlippedNormals, en markedsplads for computergrafik, der var vokset ud af WordPress, væk fra Heroku og over på AWS, var udløseren præcis den afvejning, der er nævnt ovenfor: Herokus administrerede dynos gav os begrænset kontrol over skalering, efterhånden som kataloget voksede, så vi migrerede platformen til AWS og fuldførte første etape på to måneder, sideløbende med en databaseflytning fra MySQL til PostgreSQL. En infrastrukturmigrering af den kaliber er der, hvor YAML-delen af denne artikel holder op med at være teori: deployment-processen beskrives, gennemgås og versionsstyres i konfigurationsfiler, som redigeres manuelt.
JSON-delen dukkede op i samme system, i de payloads som markedspladsens tjenester sendte mellem hinanden: maskinskrevne, læst tusindvis af gange, aldrig redigeret manuelt. Samme system, begge formater, hver især til det, de er bedst til.
For de fleste teams er dette ikke en æstetisk beslutning. Regningen lander fem steder.
Konfigurationsfejl, der når produktion. YAMLs følsomhed over for mellemrum og typeinferens betyder, at en fil kan være gyldig og forkert på samme tid. Ingen parser fanger den type fejl: kun et skematjek gør, eller at deploymenten fejler klokken tre om eftermiddagen. Ethvert repository, hvor YAML driver infrastrukturen, har brug for skemavalidering og en formateringsenhed i continuous integration, og det kræver ingeniørtid at opsætte og vedligeholde.
Sikkerhed ved parseren. YAMLs fulde loader kan konstruere vilkårlige objekter ud fra et dokument, hvilket i stilhed forvandler en anmodning om at parse en fil til en tilladelse til at køre, hvad end filen beskriver, så snart inputtet ikke er betroet. Det er derfor, biblioteker tilbyder en sikker indlæsning, hvor PyYAMLs safe_load er den mest kendte, og hvorfor den bør være standard i enhver kodebase, der læser YAML, den ikke selv har skrevet. JSON har ingen tilsvarende eksponering, da formatet ikke kan beskrive en type, der skal instansieres.
Onboarding-tid. JSON er velkendt for alle, der har brugt et API. YAML har anchors, aliases, block scalars og flere dokumenter pr. fil, og en ny medarbejder møder det hele i sin første uge med Kubernetes. Sæt tid af til oplæring, eller standardisér på et dokumenteret undersæt og få det på skrift.
Parsing-overhead ved skalering. For en konfigurationsfil, der læses én gang ved opstart, er parsing-omkostningen underordnet. For en tjeneste, der deserialiserer tusindvis af payloads i sekundet, er det ikke tilfældet, og den mindre JSON-grammatik er billigere at behandle.
Miljøer med blandede formater. Det dyre resultat er ikke det ene eller det andet format. Det er begge dele: konfiguration i YAML, fixtures i JSON, et konverteringslag klemt ind imellem dem, og to sæt valideringsregler, der driver fra hinanden over atten måneder. Vælg ét format pr. formål, skriv beslutningen ned, og valider hver især med et skema: JSON Schema på JSON-siden og et af YAML-skemaværktøjerne på den anden.
Fire spørgsmål, vi gennemgår, før vi beslutter os for et serialiseringsformat til et projekt.
Oftest peger svarene ikke på ét enkelt format for hele systemet. På de fleste af de platforme, vi bygger, ender opdelingen samme sted: YAML til det, mennesker vedligeholder – pipelines, manifester og miljøkonfiguration – og JSON til det, tjenester sender mellem hinanden. Den fejl, vi ser oftest, er ikke at vælge det forkerte format; det er at lade begge dele sprede sig til den samme opgave, uden at nogen tager stilling til, hvad der hører til hvor.
Nej. JSON parses hurtigere, fordi dets grammatik er begrænset til én side og ikke tillader tvetydighed, mens YAML-specifikationen er langt større og kræver typeinferens. Forskellen er irrelevant for en konfigurationsfil, der kun læses ved opstart, men den betyder noget for en tjeneste, der løbende parser payloads.
Ja. YAML er et supersæt af JSON, så ethvert gyldigt JSON-dokument er også gyldig YAML, og en YAML-parser læser en .json fil uændret. Det omvendte er ikke tilfældet: en JSON-parser kan ikke læse YAML.
.json fil?En almindelig tekstfil, der indeholder et enkelt JSON-dokument, gemt med filendelsen .json . Den indeholder et objekt eller et array i roden, bruger anførselstegn omkring nøgler og værdier, og kan åbnes i enhver teksteditor.
En almindelig tekstfil gemt som .yaml eller .yml , der indeholder et eller flere YAML-dokumenter. Den bruger indrykning i stedet for parenteser, understøtter kommentarer og er standardformatet for konfiguration til værktøjer som Kubernetes, Docker Compose og Ansible.
YAML, fordi det er det, økosystemet er skrevet i, og manifester redigeres og gennemgås af mennesker. Kubernetes accepterer den tilsvarende JSON-version, men hvert eneste eksempel, selvstudium og genereret manifest, du støder på, vil være i YAML.
I alle arkiver, hvor mere end én person redigerer YAML, ja. En formateringsenhed kombineret med en linter i CI fanger de indryknings- og typeinferensfejl, som en parser gladeligt accepterer, men som en klynge senere afviser.
Kun med en sikker loader. Den fulde loader kan instantiere vilkårlige objekter beskrevet i dokumentet, så parsing af en ikke-betroet fil kan eksekvere kode. Brug den sikre variant, som dit bibliotek tilbyder, såsom PyYAML's safe_load, hvor end filen ikke stammer fra dit eget arkiv.
Når et program skriver eller læser filen frem for et menneske: API-nyttelaster, beskedkøer, loglinjer, test-fixtures, browserlagring. Vælg YAML, når et menneske vedligeholder filen og har brug for kommentarer og en struktur, der er let at overskue.
Ja, og de fleste YAML-biblioteker gør det med en enkelt linje kode. Konvertering fra YAML til JSON medfører tab af kommentarer og ankre, så betragt YAML som kilden og JSON som det genererede artefakt, aldrig omvendt.
Valg af serialiseringsformat er en lille beslutning med langtrækkende konsekvenser, og det er som regel den mindst interessante del af et meget større arkitekturspørgsmål. Hvis du overvejer, hvordan dine tjenester skal udveksle og lagre data, er vores ingeniørteam klar til at drøfte det med dig.
Indholdsforfatter og digital medieproducent med interesse i det symbiotiske forhold mellem teknologi og samfund. Bøger, musik, og guitarer er en konstant.
Alexandra Mendes er Senior Growth Specialist hos Imaginary Cloud med 3+ års erfaring med at skrive om softwareudvikling, AI og digital transformation. Efter at have gennemført et frontend-udviklingskursus fik Alexandra nogle praktiske kodningsevner og arbejder nu tæt sammen med tekniske teams. Alexandra brænder for, hvordan nye teknologier former erhvervslivet og samfundet, og hun nyder at omdanne komplekse emner til klart og nyttigt indhold for beslutningstagere.
People who read this post, also found these interesting:
.webp)
