Http-Header, Datenformat und Internationalisierung

Es wird zwischen den zu übertragenden und den zu empfangenden Daten unterschieden. 
Der Client bestimmt über HTTP-Header über die Parameter content-type und accept in welchem Format er Daten sendet und in welchem er Daten empfängt.

Wird kein oder kein bekanntes Empfangs-Format übergeben wird als Standard JSON zurückgegeben.

Gültige Formate sind:

Attribut

Senden:

content-type

Empfang:

accept

Info

application/x-www-form-urlencoded

x

-

Daten URL-Encoded

application/json

x

x

Daten in JSON

application/xml

x

x

Daten in XML, Null-Werte werden wie Leerstrings behandelt

application/octet-stream Wird nur akzeptiert, wenn ein einziges binäres Feld gelesen, eingefügt oder aufdatiert werden soll.

x

x

Binäre Daten, in Entwicklung

text/plain

-

x

Formatierte Felder werden als Text ausgegeben. Felder können intern in RTF oder HTM formatiert gespeichert sein. In der REST-Schnittstelle ist dies nicht immer erwünscht. Mit dieser Option werden die Daten als unformatierter Text ausgegeben.

[ fullmeta | nometa | compact ]automatische Erkennungx

Das auszuliefernde Datenformat kann angegeben werden:

fullmetaDie Daten werden nach Meta- und Nutzdaten getrennt ausgegeben
nometaSelbe Struktur wie fullmeta, jedoch ohne den Metadaten-Block, für minimale Netzlast
compact Einfache Datenstruktur, in der Feldname und Daten zusammen ausgegeben werden ("Normales" Format)

Bei der Annahme von Daten erkennt der Server das Format automatisch.


Die Sende- und Empfangs-Format sind frei kombinierbar, ebenso gewisse accept-Optionen untereinander.

Bsp. Ausgabe in JSON und Konvertierung formatierter Texte in reinen Text: 

accept: application/json;text/plain;compact


Internationalisierung 


Falls sprachabhängige Daten zurückgegeben werden, kann die zu verwendende Sprache über den http-Header accept-language gesteuert werden.

Gültige Werte im Standard sind de, fr, it, en. Es können je nach Projekt auch andere Werte freigegeben werden.

Wird keine Sprache angegeben, wird der Systemstandard verwendet. In der Regel ist das de.

Attribut

Senden:

accept-language

Empfang:

-

Info

[de, fr, it, en]

x

-

Sprachkürzel in der die Antwort erwartet wird

Bezeichnung der Datentypen

In den Felddefinitionen werden folgende Datentypbezeichner verwendet:

BezeichnerBeschreibung
numNumerischer Wert
intInteger
boolBoolscher Wert, 1|0 oder True|False
refInteger , Referenzwert zu einer anderen Entität
keyInteger, Primärschlüssel
stringZeichenkette
bin

Binärdaten, base64 codiert


Bei Bildern werden folgende Formate unterstützt. Bei der zweiten Spalte handelt es sich um die Anfangs-Hex-Werte des dekodierten base64-Strings. Damit kann das Bildformat bestimmt werden.

FormatHEX-Wert
.bmp (bitmap)42 4D
.png (portable network graphics)89 50 4E 47
.ico (icon)00 00 01 00
.jpg / .jpegFF D8
.wmf (windows metafile)D7 CD C6 9A
.gif (graphics interchange format)47 49 46
akAls Zusatz, Alternativschlüssel, muss eindeutig innerhalb der Tabelle sein


Die maximale Länge wird in eckigen Klammern angegeben:

FormatBeschreibung
string[40], akZeichenkette maximal 40 Zeichen, Alternativschlüssel
num[6,2]  Numerischer Wert, total 6 Stellen, 2 Präzision Nachkommastellen.
bin[50k] Binärdaten, maximal 50 kB Rohdaten, muss base64 codiert sein.

Lesen von Views

In Views können Daten aus unterschiedlichen Entitäten aufbereitet und in einer denormalisierten Form und/oder in einer hierarchischen Form ausgegeben werden. Felder der Sublisten werden mit „->“ angegeben.

Views können nur gelesen werden. Alle View-Abfragen haben die Pfad-Erweiterung /view.

View-Abfragen können mit Filter eingeschränkt werden. Folgende Filtertypen sind vorhanden:

FilterBeschreibung
EPEinzelwert, Pflichtfilter, z.B. die ID
EOEinzelwert, optional, z.B. DatumVon
ETEinzelwert, optional, sucht den Filtertext innerhalb des Feldes (techn. contains, like etc.)
MMehrfachwerte oder gar keine Werte, optionaler Filter