Endpunkte, JSON im Body
Hallo,
ich wünsche mir folgende Funktionen bzw. Eigenschaften für MonkeyOffice Connect:
* Endpunkte
z.B
/firma
/adresse
/offeneposten
Nur Nomen.
Dann http-Methoden GET, POST, PUT, DELETE
GET /2 würde alle Informationen der Firma mit der ID 2 ausspucken.
DELET /2 würde die Firma mit der ID 2 löschen.
Analog würde das für alle Teile in MO funktionieren.
GET /1/adressen würde alle Adresseinträge der Firma mit der ID 1 anzeigen
ich denke, es ist klar worauf ich hinaus will.
Zu den Methoden:
GET liest die Ressource aus
POST kreiert die Ressource
PUT macht ein Update der Ressource
DELETE löscht die Ressource
und fast das Wichtigste: Request und Response als JSON im body, nicht im Header. Wie so eine echte API. Dann muss man nämlich nicht jedes Mal den API Connector für MO neu schreiben wenn der Kunde wieder so eine fancy Sprache für seine Tools benutzt, sondern einfach die Standard- RESTful API Bibliotheken nehmen, die eh so rumfliegen. Hach, das wäre schön.
-
Hallo Stephan
eventuell liegt hier ein Missverständnis vor. Die JSON-Strukturen, wie auch die SOAP-Daten, werden nicht im Header übertragen, der Datenrequest erfolgt als POST-Request in der üblichen Form. Über den Header wird nur die Firma selektiert. Die Response erfolgt dann als ganz normaler http-Content.
Zu der Frage der Verwendung von REST, dies wurde aus verschiedenen Gründen nicht realisiert. Connect entstand ursprünglich als SOAP-Schnittstelle. Um eine Verwendung auch ohne großen XML-Overhead zu ermöglichen wurde JSON hinzugefügt. REST zu verwenden hätte bedeutet, eine zweite API zu pflegen. Wenn Du die beiden Möglichkeiten , Connect (via SOAP und/oder JSON) zu nutzen, betrachtest, wirst Du eine starke Ähnlichkeit feststellen. Beide Schnittstellen können intern auf die gleiche Weise geparst, validiert und verarbeitet werden , alle höheren Verarbeitungs-Schichten sind gleich. Das hat für uns natürlich immense Vorteile.
Weiterhin ist der Zugriff über einfache Endpunkte in der vor Dir beschriebene Form nicht ausreichend, da bestimmte Daten-Selektionen z.B. über Filterdaten erfolgen, welche ja auch irgendwie zum Server übertragen werden müssen. Das wäre sicherlich mit REST auch möglich, würde die Sache aber weiter komplizieren und die beiden Schnittstellen noch weiter voneinander entfernen. Nicht zuletzt spielten aus unserer Sicht auch Sicherheitsbedenken eine Rolle.Für die Zukunft ist geplant, Connect eher funktionell weiterzuentwickeln. Eine weitere Zugriffs-API ist derzeit nicht in Planung.
-
Danke für die schnelle Rückmeldung,
für Filter gibt es ja auch genug Standards in der API Welt -
GET /adresse/filter?name='urbach'&ort='berlin' würde dann alle Adress-IDs ausspucken, auf die diese Kriterien zutreffen (jetzt nur als plattes Beispiel)
aber nun gut, das ist ja müßig zu diskutieren.
Nunja, sicherheitsbedenken - ich habe letztens erst versucht, ein Let's Encrpyt Zertifikat in MonkeyOffice Connect zum importieren - das war auch eher unschön, aber nachher lief es.
Ich habe mir schon die beiden Schnitttstellen angeschaut, brauchte ja Connectoren in GO und für nodes.js. Ich denk mir halt, eine API, die nicht mit den Standarad API-Bilbiotheken ohne größere Anpassunge anwendbar ist, ist jetzt nicht zwingend die Beste.
Alleine schon, dass für die Firma nicht einfach die Nummer übergeben werden kann sondern erst fuddelig eine lange ID ausgelesen werden msus ist halt eine Designentscheidung, die ich nicht verstehen muss, aber gerne würde um mich nicht jeden Tag zu ärgern. Ich habe zuletzt ein Importer für Offene Posten geschrieben. Jetzt sind da drei Firmen in der Datenbank - wo ich umständlich IDs auslesen muss um sie dann zu übergeben oder(!) ich mach drei config Files und starte das tool dreimal. Ich hab jetzt umständlich gebaut, dass ich mit einmal starten drei Dateien importieren kann und das tool halt fragt, welche Firma es denn sein darf und dann diese nicht nachvollziehbare ID nutzt. Mit mehr Endpunkten wäre es dann /1/ /2/ oder /3/.
Ich gebe zu, ich habe mir den traffic nicht genau angeschaut, in MO Connect gibt es zwar ein Log, aber das ist unbrauchbar, weil ich das ja nicht mal wegspeichern kann (oder ich bin zu blöd, die Funktion zu finden) um mir anzuschauen, was da denn genau passiert. Für eine API ist das unbefriedigend. genauso wünsche ich mir ja auch noch die Funktion "productive" und "testing" - letztere zeigt dann hal nur an, was passiert wäre, wenn das jetzt so usgeführt worden wäre. Nun ja, ich geh mal weiter träumen :)
-
Hallo Stephan
Was die ID betrifft, diese sind fest und werden intern nach einem bestimmten Schema gebaut, wo nicht nur Infos zu der eigentlichen RowID, sondern auch Infos zur Semantik, also eine ID für Datensatz 1 von z.B Adressen ist unterscheidbar von der ID 1 von, sagen wir, Aufträgen. Wenn Du also eine Firmen-ID in deinen Scripten hart-kodieren willst, sollte auch das kein Problem sein, einfach im Testclient auslesen . Alle anderen ID sind eh dynamisch, und müssen Verwendung über Connect ausgelesen werden.
Was das Log betrifft, vielleicht wird es für Dich einfacher, wenn Du mal Copy und Paste benutzt, in Verbindung mit alles auswählen ? In den Einstellungen kannst Du das Level festlegen, bis zur Anzeige alle übertragenden Daten. Ich denke mal, das hilft Dir weiter.
Für die Entwicklung ist es auch hilfreich, den Testclient zu benutzen.
Ich glaube, die Diskussion über bestimmte Details sollten wir vielleicht per Mail weiterführen, ansonsten würde das hier zu weit führen.
Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.
Kommentare
5 Kommentare