Hallo,
wir integrieren derzeit Ihre REST API in unsere Anwendung und benötigen einige Klarstellungen bezüglich Authentifizierung, Token-Lebensdauer und einer möglichen Keep-Alive-Strategie.
Basierend auf der Dokumentation und unseren Tests verstehen wir das Verhalten aktuell wie folgt:
POST /Login ist erforderlich, um eine gültige LoginId für die Autorisierung zu erhalten.
POST /Logout macht die aktuelle LoginId sofort ungültig.
GET /Users/Current liefert Informationen über den aktuell angemeldeten Benutzer, scheint aber kein Token-Refresh-Endpunkt zu sein.
In unserer Umgebung erzeugt jeder Login einen zusätzlichen laufenden Backend-Prozess im Mobile Manager.
Wenn kein Logout erfolgt, bleiben diese Prozesse aktiv bestehen.
Wenn ein Logout erfolgt, ist die LoginId nicht mehr verwendbar, was für langlaufende Integrationen problematisch ist.
Dadurch ergibt sich für uns aktuell ein technischer Zielkonflikt.
Wir bitten daher um Klärung der folgenden Punkte:
Wie lange ist eine LoginId nach POST /Login gültig?
Gibt es einen definierten Timeout für Token bzw. Sessions?
Verlängert ein Aufruf von GET /Users/Current die Lebensdauer der Session oder hält diese aktiv?
Gibt es einen offiziellen Keep-Alive- oder Refresh-Mechanismus für langlaufende Integrationen?
Gibt es einen empfohlenen, leichten Endpunkt, der regelmäßig aufgerufen werden kann, ohne zusätzliche Backend-Prozesse zu erzeugen?
Ist es vorgesehen, dass jeder Login einen neuen Backend-Prozess im Mobile Manager erzeugt?
Wie ist der empfohlene Umgang für Dienste oder Integrationen, die dauerhaft auf die API zugreifen müssen?
Sollte man eine bestehende Session möglichst lange offen halten oder regelmäßig Login/Logout durchführen?
Aktuell sehen wir folgendes Problem:
Für API-Zugriffe wird eine gültige LoginId benötigt.
Jeder Login scheint einen neuen Backend-Prozess zu erzeugen.
Ein Logout macht die LoginId sofort ungültig.
Dadurch ist für uns aktuell nicht klar, wie ein stabiler und ressourcenschonender Betrieb (z. B. mittels Heartbeat/Keep-Alive) technisch korrekt umgesetzt werden kann.
Über eine technische Empfehlung oder Best Practice würden wir uns sehr freuen.
Mit freundlichen Grüßen
Hallo,
wir integrieren derzeit Ihre REST API in unsere Anwendung und benötigen einige Klarstellungen bezüglich Authentifizierung, Token-Lebensdauer und einer möglichen Keep-Alive-Strategie.
Basierend auf der Dokumentation und unseren Tests verstehen wir das Verhalten aktuell wie folgt:
POST /Login ist erforderlich, um eine gültige LoginId für die Autorisierung zu erhalten.
POST /Logout macht die aktuelle LoginId sofort ungültig.
GET /Users/Current liefert Informationen über den aktuell angemeldeten Benutzer, scheint aber kein Token-Refresh-Endpunkt zu sein.
In unserer Umgebung erzeugt jeder Login einen zusätzlichen laufenden Backend-Prozess im Mobile Manager.
Wenn kein Logout erfolgt, bleiben diese Prozesse aktiv bestehen.
Wenn ein Logout erfolgt, ist die LoginId nicht mehr verwendbar, was für langlaufende Integrationen problematisch ist.
Dadurch ergibt sich für uns aktuell ein technischer Zielkonflikt.
Wir bitten daher um Klärung der folgenden Punkte:
Wie lange ist eine LoginId nach POST /Login gültig?
Gibt es einen definierten Timeout für Token bzw. Sessions?
Verlängert ein Aufruf von GET /Users/Current die Lebensdauer der Session oder hält diese aktiv?
Gibt es einen offiziellen Keep-Alive- oder Refresh-Mechanismus für langlaufende Integrationen?
Gibt es einen empfohlenen, leichten Endpunkt, der regelmäßig aufgerufen werden kann, ohne zusätzliche Backend-Prozesse zu erzeugen?
Ist es vorgesehen, dass jeder Login einen neuen Backend-Prozess im Mobile Manager erzeugt?
Wie ist der empfohlene Umgang für Dienste oder Integrationen, die dauerhaft auf die API zugreifen müssen?
Sollte man eine bestehende Session möglichst lange offen halten oder regelmäßig Login/Logout durchführen?
Aktuell sehen wir folgendes Problem:
Für API-Zugriffe wird eine gültige LoginId benötigt.
Jeder Login scheint einen neuen Backend-Prozess zu erzeugen.
Ein Logout macht die LoginId sofort ungültig.
Dadurch ist für uns aktuell nicht klar, wie ein stabiler und ressourcenschonender Betrieb (z. B. mittels Heartbeat/Keep-Alive) technisch korrekt umgesetzt werden kann.
Über eine technische Empfehlung oder Best Practice würden wir uns sehr freuen.
Mit freundlichen Grüßen