REST Urls der API
- Dieses Thema hat 10 Antworten und 5 Stimmen, und wurde zuletzt aktualisiert vor 2 Jahren, 6 Monaten von
.
-
Beiträge
-
Hallo zusammen,
wie wird denn die REST URL der API zusammengesetzt?
Das Handbuch hat da zwar ein paar Beispiele, aber richtig klar ist es nicht.
Und der PHP Beispielcode funktiniert selbst auch nicht 😉z.B: funktioniert in meinem Code:
„/ica/rest/nami/search-multi/result-list“ einwandfrei.Aber ich bekomme das nicht mit api/1/2/ … hin.
Gruß Daniel
Hallo Daniel,
es gibt zwei Methoden auf NaMi zuzugreifen:
1) den offiziellen Zugang über die API
2) den „inoffiziellen“ Zugang, indem man sich als Webclient ausgibtDie beiden Methoden unterscheiden sich neben den aufgerufenen REST-URLs (also den Teil mit api/1/2) noch im genauen Ablauf für den Login.
Um Variante 1 nutzen zu können, muss dein Benutzer extra freigeschaltet werden (dazu beim Namisupport anfragen). Variante 2 kann logischerweise jeder nutzen.Die Unterschiede im Login-Vorgang zwischen den beiden Varianten kannst du z. B. hier in meinem Programm in der Funktion namiLogin() sehen:
https://github.com/fabianlipp/jnami/blob/master/src/nami/connector/NamiConnector.javaWie sich die URLs genau zusammensetzen ist bisher wohl nirgends dokumentiert. Momentan ist es hier das einfachste die Kommunikation zwischen Webclient und Server im Browser zu beobachten (z. B. mit Firebug für Firefox).
Viele Grüße,
FabianHi Fabian,
ja so hab ich das auch gelesen/verstanden 🙂In Nami (bzw. namitest) bekomme ich mich eingeloggt. Und kann über die Nicht-API Urls auch Daten auslesen.
Was mir noch nicht ganz klar ist:
Ich glaube, ich habe das Login richtig. Ich setzte „Login“ auf „API“ und bekomme nach dem 302 direkt eine JSON Antwort.
Allerdings hole ich mir die „Session“ aktuell über die Cookies – ist das bei API Zugriff falsch? Oder ist das egal?Gibt es eine klare Fehlermeldung, wenn meinem Testnutzer API Rechte fehlen?
Zum Thema Firebug? Woran erkenne ich ob ein Zugriff „Api-umsetzbar“ ist und welche nicht? Oder ist prinzipiell die ganze Ajax Kommunikation von ExtJS mit dem (JBoss) Backend auf die API umsetzbar und ich habe schlicht den Login-Falsch oder keine API Rechte auf dem Testsystem?
Danke für deine Hilfe 🙂
Gruß Daniel
Hi,
Allerdings hole ich mir die „Session“ aktuell über die Cookies – ist das bei API Zugriff falsch?
Das müsste so stimmen. Ich habe das bei mir jedenfalls auch so umgesetzt. Ist allerdings schon eine Weile her, dass ich damit rumexperimentiert habe.
Gibt es eine klare Fehlermeldung, wenn meinem Testnutzer API Rechte fehlen?
Ich meine ich habe da beim Login mal eine Fehlermeldung (Statuscode >= 3000) bekommen, weil mir die Rechte gefehlt haben. Liefert bei dir der Login den Statuscode 0 (Erfolg)?
Woran erkenne ich ob ein Zugriff „Api-umsetzbar“ ist und welche nicht?
Meines Wissens ist jeder der REST-Aufrufe auch per API möglich.
Viele Grüße,
FabianHallo zusammen,
die ursprüngliche Idee von NaMi 2.x war ja, dass es einen Kern mit der Business-Logic insbesondere der Rechteverwaltung gibt und dass der WebClient selbst auch nur ein Nutzer der API ist.
Ganz 1:1 ist das Konzept nicht umgesetzt, aber in groben Zügen stimmt das so.Der Unterschied der „Offiziellen“ NaMi-Aufrufe gegenüber der REST-Calls, die über die Web-Schnittstelle gehen ist die Stabilität. Die offizielle API wird bei Änderungen versioniert und steht dann immer noch zur Verfügung, auch wenn sich die Aufrufe in der Webschnittstelle ändern.
Das Ganze ist in gewissen Grenzen hier beschrieben: https://doku.dpsg.de/display/NAMI/Service+Architektur
Ich schau mal, wie wir die Dokumentation an diesem Punkt noch verständlicher machen können.
Viele Grüße
DanielHi Daniel,
und wieder, wie so oft 🙂 danke!Ich hab meinen/den Fehler inzwischen gefunden:
/ica/rest/nami/search-multi/result-list
ist nicht über die API verfügbar./ica/rest/nami/search/result-list
ist über die API verfügbar.Mit Firebug konnte ich leider keine entsprechenden Anfragen mehr sehen, aber dank Fabians Code ist es ja nicht wirklich schwer das Anfrage-JSON Objekt nachzuvollziehen 🙂
Lg
DanielInteressant. Das wurde wohl geändert, als das Suchformular umgestaltet wurde. Als ich meine Klassen programmiert habe, habe ich das auch über Firebug ausgelesen. Damals hat also auch das Suchformular im Webclient noch /ica/rest/nami/search/result-list genutzt.
Das heißt wir benötigen jetzt doch langsam mal eine ordentliche API-Dokumentation, wenn es jetzt API-Aufrufe gibt, die über das Web-Interface nicht auffindbar sind.
Nach 4 Jahren hier nochmal schreiben… Mal schauen. Gibt es mittlerweile eine ordentliche API-Dokumentation? Oder wie finde ich raus, welche Pfade ich aufrufe um etwas zu bekommen
Hallo Janneck,
leider nicht. Ich hab hier eine Liste von Dingen die wir seit ca 4 Jahren gerne hätten…
im Juni/Juli haben wir jetzt mal wieder ein Treffen mit der Firma wo ich das alte Protokoll nochmal vorlesen werde.
Die Firma war die letzten 2 Jahre ordentlich mit ihrer eigenen Abwicklung und Neugründung beschäftigt.Zur Doku: Wir müssten sie wahrscheinlich selbst verfassen.
Bedingt durch den Beschluss IA3 der Bundesversammlung 2019 https://dpsg.de/fileadmin/daten/dokumente/bundesversammlungen/85bv/ergebnisse/IA3_Evaluation-Konzeptentwicklung-Digitales_beschlossen.pdf
sind jetzt natürlich viele Fragen offen und es wird sich zeigen, ob wir Zeit und Geld in die bisherige Lösung (u.a. Umbau der Weboberfläche auf HTML5) investieren wollen oder bald mit einer Neuentwicklung beginnen. In diesem Fall hoffe ich persönlich, dass wir dann auf einen OpenSource-Entwicklungsprozess umschwenken. Mal sehen.Hallo zusammen, ich würde ebenfalls gerne Nami über die API ansprechen. Das vollständigste was ich gefunden habe ist die Doku von pynami (https://pynami.readthedocs.io/en/latest/). Allerdings weiß ich auch nicht, ob das NaMi 1.0 oder 2.x ist.
Gibt es irgendwo eine Liste der verfügbaren Endpunkte und Requests, die man abfeuern kann?Viele Grüße
- Du musst angemeldet sein, um zu diesem Thema eine Antwort verfassen zu können.