Für den Verbindungsaufbau zur Api ist kein weiterer Service oder Prozess nötig. Die Api wird als Sub-Url des Webfrontend benutzt.
Wenn man also das Webfrontend unter der Url https://corvus.firmenname.de:13472/corvusYuna/ erreichen kann,
dann kann man die Api unter https://corvus.firmenname.de:13472/corvusYuna/apiYuna erreichen.
Es gelten dabei exakt die gleichen Randbedingungen, als wenn der Client Host auf das Webfrontend zugreifen würde. Das könnte also Firewall Regeln, Proxy Regeln und sonstiges betreffen.
Das bedeutet im Umkehrschluss, jeder Client, der auf das Webfrontend zugreifen kann, kann alternativ auch die Api benutzen, und umgekehrt. Es gibt keine Unterscheidung.
Als Transport Schicht wird das Protokoll HTTP benutzt. Wobei HTTP Version 1 und 2 aktuell unterstützt werden. Postmoderner Unfug mit Pipelining und Streams und What-Not wird nicht unterstützt.
Als Method von HTTP wird nur ein POST unterstützt. Ein GET wird nicht unterstützt. Die Api erwartet als Anweisung ein JSON,
und ein GET mit Content ist in keiner RFC spezifiziert und auch teilweise von diversen Libraries nicht unterstützt, was gut ist.
Der POST muss immer, oder sollte immer, ein Accept Header beinhalten. Es gibt Client Software, die möglicherweise dort
einen Fehler werfen, wenn der Accept-Header nicht passt. Der Server prüft das jedoch nicht, ist ihm auch egal.
Hier ein paar einfache Beispiele mit Fehlermeldungen
$ wget https://corvus.firmenname.de:13472/corvusYuna/apiYuna
HTTP request sent, awaiting response... 405 Method Not Allowed
ERROR 405: Method Not Allowed.
$ curl -v https://corvus.firmenname.de:13472/corvusYuna/apiYuna
< HTTP/1.1 405 Method Not Allowed
Sowohl wget also auch curl senden beide natürlich ein GET Request, wenn man nichts sagt. Diese Methode ist nicht erlaubt.
In diesem Fall wird in der Transportschicht der Status HTTP 405 Method Not Allow gesetzt.
$ wget --post-data 'blabla' https://corvus.firmenname.de:13472/corvusYuna/apiYuna
HTTP request sent, awaiting response... 406 Not Acceptable
ERROR 406: Not Acceptable.
$ curl -d 'blabla' -v https://corvus.firmenname.de:13472/corvusYuna/apiYuna
< HTTP/1.1 406 Not Acceptable
Der HTTP Status 406 Not Acceptable wird immer dann geliefert, wenn der Body kein gültiges JSON aufgewiesen hat. In dem Beispiel wird einfach eine sinnlose Zeichenkette übertragen. Das kann nicht als JSON gelesen werden, und somit ist das auch nicht akzeptierbar, was dort gekommen ist.
Um Daten als POST zu übertragen, kann man bei wget die Option --post-data verwenden, bei curl geht das mit -d.
Man kann bei beiden auch eine Datei angeben, wo dann das JSON drin steht.
Internal Server Error wird nur dann ausgegeben, wenn zum Beispiel bei einem Download was fehlschlägt.
Es gibt API Aufrufe, die kein JSON zurückliefern, sondern ein Binärformat (Report-Download zum Beispiel). Da es dort keine Möglichkeit gibt ein Fehler sinnvoll zu übermitteln, wird hier ein Internal Server Error verwendet.
$ wget -q -O - --post-data '{}' https://corvus.firmenname.de:13472/corvusYuna/apiYuna | jq
{
"requestStatus": {
"isError": true,
"errorMessage": "No valid authKey found"
},
"timingInformation": {
"serverReceivedTimestampUtcMs": "29119"
}
}
Mit wget kann man die Option -q setzen, das verhindert irgendwelche Statusmeldungen oder Download Meldungen.
Mit -O - wird der Download nicht mehr in eine Datei geschrieben, sondern auf STDOUT ausgegeben.
Das Program jq sogt dafür, dass das JSON toll aussieht, und nicht in einer Zeile dargestellt wird.
$ curl -s -d '{}' https://corvus.firmenname.de:13472/corvusYuna/apiYuna | jq
{
"requestStatus": {
"isError": true,
"errorMessage": "No valid authKey found"
},
"timingInformation": {
"serverReceivedTimestampUtcMs": "291200"
}
}
Das Gleiche geht auch mit curl, wobei hier -s dafür sorgt, das die curl Statusmeldungen verschwinden.
Hier sieht man aber das ein Fehler nun nicht mehr von der Transportschicht bearbeitet wird, sondern direkt in der Antwort. Mehr dazu findet man unter Fehlermeldungen.
Corvus Help - 28.February 2026 03:33:38 UTC - Commit 667ccc2e