HIT V.3 REST-API Dokumentation

Liefere Liste der in der ZD bekannten Meldeentitäten.

Liefere Liste bestimmter Meldeentität oder, wenn nicht gefunden, Meldeentität als Namensbestandteil

Liefere Liste der Meldeentitäten, die zum bestimmten Melde-Typ gehören.

Liefere Spalten zur gegebenen Meldeentität oder, wenn nicht gefunden, Meldeentität als Namensbestandteil

Liefere Codes zum gegebenen Codeset oder, wenn nicht gefunden, Codeset als Namensbestandteil

Abrufen von Daten eines oder mehrerer Bestandsregister. Aufruf und Parameter orientieren sich an den entspechenden HIT-Funktionen #BESTREG usw. Dokumentation dazu siehe HIT-Entwicklungsbereich unter https://www.hi-tier.de/Entwicklung/Konzept/HITP/feink045.html#BESTREG .

Umwandeln einer beliebig formatierten Ohrmarke in die numerische bzw. alphanumerische normierte Darstellungsform. Liefert immer HTTP Status 200. Die Schwere zeigt an, ob die Ohrmarke korrekt ist oder nicht: ist sie kleiner 2, ist so korrekt, sonst fehlerhaft.

Umwandlung in Alpha-Darstellung der Rinder-Ohrmarke. Es wird nur die Zeichenkette mit der alphanumerischen Ohrmarke geliefert, kein Json etc! Ist die Ohrmarke falsch oder nicht rein numerisch, wird ein "Bad request" (HTTP 400) mit der Fehlermeldung als "Message" geliefert.

Umwandlung in numerische Darstellung der Rinder-Ohrmarke. Es wird nur die 15stellige Zahl der Ohrmarke geliefert, kein Json etc! Ist die Ohrmarke falsch, wird ein "Bad request" (HTTP 400) mit der Fehlermeldung als "Message" geliefert.

Umwandeln einer beliebig formatierten Betriebsnummer in die numerische bzw. alphanumerische normierte Darstellungsform. Liefert immer HTTP Status 200. Die Schwere zeigt an, ob die Betriebsnummer korrekt ist oder nicht: ist sie kleiner 2, ist so korrekt, sonst fehlerhaft.

Umwandlung in Alpha-Darstellung einer Betriebsnummer. Es wird nur die Zeichenkette mit der alphanumerischen Betriebsnummer geliefert, kein Json etc! Ist die Betriebsnummer falsch oder nicht rein numerisch, wird ein "Bad request" (HTTP 400) mit der Fehlermeldung als "Message" geliefert.

Umwandlung in numerische Darstellung der Betriebsnummer. Es wird nur die 15stellige Zahl der Betriebsnummer geliefert, kein Json etc! Ist die Betriebsnummer falsch, wird ein "Bad request" (HTTP 400) mit der Fehlermeldung als "Message" geliefert.

Prüft Verfügbarkeit des Rest-Services und gibt Version zurück. Aufruf: GET /api/hitcom

Führt 1..n HIT-Abfragen (GET = RS) aus und gibt deren Antworten zurück. Die Anfrage besteht aus den Elementen Subcode für Zusatzparameter beim RS, Meldung (z.B. GEBURT), Feldliste (z.B. BNR15;LOM;GEB_DATR/S) und Datenliste, die in mehreren Zeilen die zur Feldliste passenden Daten enthält.

POST - IS Insert Inserting a Resource (Crud)

PUT - XS Execute Updating a Resource (crUd)

DELETE - SS Storno Deleting a Resource (cruD) If a DELETE request succeeds, it can return status 200 (OK) with an entity-body that describes the status; status 202 (Accepted) if the deletion is still pending; or status 204 (No Content) with no entity body. In this case, the DeleteProduct method has a void return type, so ASP.NET Web API automatically translates this into status code 204 (No Content).

Prüft Verfügbarkeit des Rest-Services und gibt Version zurück. Aufruf: GET /api/hitcom

Führt 1..n HIT-Anfragen aus und gibt deren Antworten zurück. Die Anfrage besteht aus drei Elementen: Befehl (z.B. XS/S), Meldung (z.B. GEBURT) und Daten. Die Daten sind wie eine CSV-Datei aufgebaut: die erste Zeile ist die Kopfzeile, alle weiteren Zeilen die dazupassenden Datenzeilen. Man kann hiermit jeden HITP-Befehl senden, also sowohl Abfragen als auch Meldungen. Der GET-Request ermöglicht hier lediglich eine einfache Anfrage per URL.

Führt 1..n HIT-Anfragen aus und gibt deren Antworten zurück. Die Anfrage besteht aus drei Elementen: Befehl (z.B. XS/S), Meldung (z.B. GEBURT) und Daten. Die Daten sind wie eine CSV-Datei aufgebaut: die erste Zeile ist die Kopfzeile, alle weiteren Zeilen die dazupassenden Datenzeilen. Man kann hiermit jeden HITP-Befehl senden, also sowohl Abfragen als auch Meldungen. Der POST-Request ermöglicht hier lediglich eine Anfrage per JSON- oder HTTP-Formular-Daten.

Liefere HitResponse mit Versionsnummer.

Frage anhand Entität, gewünschter Spalten und einer Bedingung einen HitServer und liefere 1..n komplexe HIT-Anworten.

Füge ein oder mehreren Meldungen der gegebenen Entität ein. Die Meldungen können entweder ein JsonObject sein, welches Spalte-Wert-Paare enthält (=ein Datensatz wird eingefügt) oder ein JsonArray mit gleichartigen JsonObjects sein (=mehrere Executes). Da das HIT-Protokoll weitere Aktionen wie Update oder Check versteht, kann der POST hier alle Aktionen ausführen, wenn sie explizit angegeben werden.

Verarbeite einen POST (=Einfügen) mit ein oder mehreren Meldungen. Da die Entität hier NICHT Teil der Route ist, können nur JsonObjects mit einer Property "entity" und einer Property "data" gemeldet werden. Die Property "data" wiederum ist entweder ein JsonObject, welches Spalte-Wert-Paare enthält (=ein Execute) oder ein JsonArray mit gleichartigen JsonObjects (=mehrere Executes).

Verarbeite einen PUT (=Ändern) mit ein oder mehreren Meldungen.

Verarbeite einen PUT (=Ändern) mit ein oder mehreren Meldungen. Da die Entität hier nicht Teil der Route ist, können nur JsonObjects mit einer Property "entity" und einer Property "data" gemeldet werden. Die Property "data" wiederum ist entweder ein JsonObject, welches Spalte-Wert-Paare enthält (=ein Insert) oder ein JsonArray mit gleichartigen JsonObjects (=mehrere Inserts).

Verarbeite ein DELETE (=Stornieren) mit ein oder mehreren Meldungen.

Beendet die angegebene Session sauber.

Prüft Verfügbarkeit des Rest-Services und gibt Version zurück. Aufruf: GET /api/hitraw

Führt 1..n HIT-Protokollbefehl(e) aus und gibt deren Antworten zurück. Man kann hiermit jeden HITP-Befehl senden, also sowohl Abfragen als auch Meldungen. Der GET-Request ermöglicht hier lediglich eine einfache Anfrage per URL. Dieser Aufruf ist kompatibel zum originalen Aufruf in RESTv1.

Führt 1..n HIT-Protokollbefehl(e) aus und gibt deren Antworten zurück. Man kann hiermit jeden HITP-Befehl senden, also sowohl Abfragen als auch Meldungen. Der GET-Request ermöglicht hier lediglich eine einfache Anfrage per URL.

Führt 1..n HIT-Protokollbefehl(e) aus und gibt deren Antworten zurück. Man kann hiermit jeden HITP-Befehl senden, also sowohl Abfragen als auch Meldungen. Der POST-Request ermöglicht hier lediglich eine Anfrage per JSON- oder HTTP-Formular-Daten.

Test für PDF-Generierung