JSON, XML & datakontrakt

Data är inte sitt format

En intern datamodell kan vara en struct eller klass. Serialisering gör modellen till ett överförbart format. Parsning tolkar texten tillbaka till data. Samma mätning kan uttryckas i både JSON och XML.

JSON
{"sensorId":"temp-01","value":21.7,"unit":"C"}

XML
<reading>
  <sensorId>temp-01</sensorId>
  <value>21.7</value>
  <unit>C</unit>
</reading>

Tre kontroller innan data får användas

Att texten kan parsas betyder inte att innehållet är korrekt. Validera i tre steg innan du sparar data eller använder det för styrning.

• Syntax: går texten att parsa som JSON eller XML?
• Struktur och typ: finns sensorId, value och unit med rätt typer?
• Semantik: är temperatur och enhet rimliga i den här domänen?

Skriv ner överenskommelsen

I kursens temperaturkontrakt är sensorId en icke-tom sträng, value ett tal mellan −50 och 100 och unit exakt C. Talet 21.7 och strängen "21.7" är olika typer i JSON.

JSON Schema kan kontrollera JSON och XSD kan beskriva XML-struktur och typer. Alla domänregler uttrycks inte automatiskt av ett schema. Content-Type anger vilken representation mottagaren ska tolka.

sensorId: string, minst 1 tecken
value: number, −50 ≤ value ≤ 100
unit: "C"
Alla tre fält är obligatoriska.

Ett fel som hjälper avsändaren

Ett bra felsvar anger vad som är fel, var felet finns och hur det kan rättas. Svara exempelvis att value måste vara ett tal i stället för att bara säga att något gick fel. Behåll samma regler genom hela IoT-kedjan.

{"error":"value måste vara ett tal","field":"value"}