Wie werde ich API/Schnittstellen Profi ?

[FreddyCollin]

Hallo liebe Leute,

ich interessiere mich sehr für API Schnittstellen und hantiere deshalb zur Zeit viel mit Microsoft Flow um zB Spotifiy oder Ebay API auszulesen, mir automatisiert Tabellen zu befüllen etc.... Bisher alles nur Hobby/Spaß Projekte.

Leider weiß ich nicht, wie ich besser werden kann in diesem Thema und wollte euch als Profis mal fragen ob ihr mir Tipps habt?

- Welche Auth. Mechanismen gibt es und warum?
- Welche komplexen API Mechanismen gibt es?
- Wie funktioniert die API - Datenbank Architektur? Wie ist dazu das Client - Server Model einzuordnen?
- Annahme: Ein Software Unternehmen hat eine Anwendung die Kundendaten generiert und schickt mir eine API Dokumentation zu, wie auf diese Kundendaten zugegriffen werden kann. Wie untersuche ich diese Dokumentation hinsichtlich dem Ziel, sie am Schluss in MS Flow zb. anbinden zu können?
- Welche Programmiersprachen brauche ich? JSON/XML sollte ich wohl verstehen...das klappt einigermaßen schon^^ Javascript? C#? SQL? Was meint ihr ist noch wichtig?

Und so weiter und so fort. Ich weiß leider nicht wie ich als dummer Laie überhaupt anfangen soll^^
Ich würde auch Geld für einen guten Kurs etc. ausgeben, weil es mir beruflich auch neue Wege bereiten könnte.

Danke für jeden Tipp

 

[Madman1209]

Hi,

erstens: entweder "API" oder "Schnittstelle". Eine "API Schnittstelle" ist doppelt gemoppelt. Und zweitens: eine pauschale Aussage gibt es natürlich nicht, weil jede Schnittstelle anders aufgebaut ist. Nimm eine konkrete Schnittstelle und mache dich mit der vertraut.

VG,
Mad

 

[benneq]

Leider weiß ich nicht, wie ich besser werden kann in diesem Thema und wollte euch als Profis mal fragen ob ihr mir Tipps habt?

Erfahrung. Selber schreiben. Auf die Nase fallen. Aus den Fehlern lernen. Verbessern.

- Welche Auth. Mechanismen gibt es und warum?

Heutzutage ist OAuth2 das präferierte Mittel. Aber es gibt auch APIs mit irgendwelchen Custom Lösungen, oder HTTP Sessions.

- Welche komplexen API Mechanismen gibt es?

Normalerweise gar keine. Es ist eine Schnittstelle. Du rufst eine Funktion auf und bekommst eine Antwort.

- Wie funktioniert die API - Datenbank Architektur? Wie ist dazu das Client - Server Model einzuordnen?

Das sollte dich als API Consumer überhaupt nicht interessieren. Ob überhaupt eine Datenbank dahinter steckt, ob eine andere API angezapft wird, oder einfach Zufallswerte ausgegeben werden, sind Implementierungsdetails des Backends. Für den Client ist nur wichtig, dass es funktioniert - nicht wie.

- Welche Programmiersprachen brauche ich? JSON/XML sollte ich wohl verstehen...das klappt einigermaßen schon^^ Javascript? C#? SQL? Was meint ihr ist noch wichtig?

JSON / XML sind keine Programmiersprachen.
Ansonsten hängt die Programmiersprache von deiner Zielplattform, deinen Kenntnissen und Vorlieben ab. Eine Web API lässt sich mit jeder Sprache konsumieren, für die es ein HTTP Modul gibt. (Und falls es keins gibt, kann man sich sowas (ziemlich umständig) natürlich auch selbst schreiben )

 

[Ebrithil]

Wie untersuche ich diese Dokumentation hinsichtlich dem Ziel, sie am Schluss in MS Flow zb. anbinden zu können?

Also wenn ich mir eine neue API angucke, dann idR nicht, weil ich die komplette API irgendwo anbinden will, sondern weil ich konkret ein Ziel erreichen will. Und dann gucke ich was mir die API anbietet, um dieses Ziel zu erreichen.

Ansonsten hängt die Programmiersprache von deiner Zielplattform, deinen Kenntnissen und Vorlieben ab. Eine Web API lässt sich mit jeder Sprache konsumieren, für die es ein HTTP Modul gibt.

Wenn mans drauf anlegt, geht das auch ohne HTTP Modul, Hauptsache man kommt irgenwie an die Netzwerkinterfaces vom OS ran

 

[FreddyCollin]

Jungs vielen Dank für euren Input. Ich weiß meine Frage ist schwammig und laienhaft formuliert! Umso mehr freue ich mich darüber, dass ihr mir schonmal ein ganzes Stück weiterhelfen konntet!!

 

[Rossie]

Im Netz dominiert heutzutage REST. Letztlich einfache HTTP-Aufrufe, die Daten in einer bestimmten Struktur liefern, die man dann weiter verarbeiten kann. Das geht mit jeder Programmiersprache.

MS Flow ist eine Möglichkeit auch ohne Programmierung verschiedene Dienste zusammenzubringen und automatisierte Abläufe zu erstellen. Um eine Anwendung in MS Flow einzubinden, muss allerdings ein entsprechender Connector vorhanden sein. Darüber wickelt man dann z.B die eigentliche Kommunikation mit der Anwendung über eine REST API ab.

API ist aber nicht auf Web-Sachen beschränkt. Sagt ja der Name schon. Anwendungen nutzen auf diesem Wege Funktionen anderer Programme oder Bibliotheken.

 

[HaZweiOh]

Warum denn ausgerechnet das kostenpflichtige Microsoft Flow?

Wenn du was Lernen willst, solltest du besser selbst programmieren. Kostenlos und plattformübergreifend. Zum Beispiel mit PHP, Python, Java, etc.

Wie untersuche ich diese Dokumentation hinsichtlich dem Ziel, sie am Schluss in MS Flow zb. anbinden zu können?

Mit MS Flow am besten gar nicht.
Du untersuchst nicht die komplette API ausführlich, sondern suchst dir nur die Funktionen raus, die du brauchst.

 

[ayngush]

Heutzutage ist OAuth2 das präferierte Mittel. Aber es gibt auch APIs mit irgendwelchen Custom Lösungen, oder HTTP Sessions.

Nö, ist es nicht? Die allermeisten APIs werden wohl immer noch im B2B-Umfeld Verwendung finden und da ist JWT der "Industriestandard" neben einfacher aufgebauten ApiKey-Mechanismen und Auth-Endpoints mit Basic Auth Anmeldung - wenn es REST-APIs sind. Bei SOAP-APIs ist so ein SAML Challenge-Response mit X.509 Auth der Standard. Bei Binary-RPC wüsste ich nicht, wie man da überhaupt eine Authentifizierung einbaut, da muss man sich garantiert etwas selber basteln über ein API-Key-Mechanismus.
OAuth2 verwendet man hauptsächlich für öffentliche REST-APIs einiger Webanbieter wie Google, Facebook, Instagram, Youtube... Damit hat man beruflich allerdings nicht so häufig zu tun, außer man wird so ein Influencer-IT-Profi.

"HTTP Sessions" / Sitzungskennzeichner und Sitzungen sind bei REST-APIs, was das aktuell häufigste API-Format neben RPC sein dürfte, absolut Tabu.

Was zum Lernen ganz gut ist ist, der Documentation-Driven Development Ansatz von Swagger, was auch gleichzeitig ein gutes Tools ist, um seine API zu Dokumentieren, denn: Eine API ist nur so gut, wie seine Dokumentation. Ist die Doku Schrott (ungenau oder unpräzise beschrieben, fehlerhaft beschrieben, auszugsweise beschrieben, gar nicht vorhanden, unvollständig, falsche Semantik, veraltet, ...), taugt die ganze API nichts.
Was sich übrigens dann als "HomeLab" eignet ist ein SmartHome von z.B. HomeMatic. Da gibt es von hause aus schon sehr viele mehr oder weniger gute APIs, die man anbinden kann und rund um das Thema Datensammlung usw. kann man sich dann mit einen kleinen Raspi HomeLab eigene APIs bauen, die man dann auswertet usw. Jedenfalls hat man da dann schon mal recht interessante Daten und kann sich da vollends mit allem austoben, was die API-Entwicklung ausmacht (Datenmodell, Auswahl der geeigneten Sprache, Definition der Kollektionen anhand des Modells, Server und Client Architekturen, usw.)

Und schmeiß das MS-Flow weg, damit lernt man nur "rumgeklicke" aber keine API-Entwicklung.

 

[benneq]

Nö, ist es nicht?

Ich versteh die Frage nicht.

Die allermeisten APIs werden wohl immer noch im B2B-Umfeld Verwendung finden und da ist JWT der "Industriestandard" neben einfacher aufgebauten ApiKey-Mechanismen und Auth-Endpoints mit Basic Auth Anmeldung - wenn es REST-APIs sind.

Ich sprach nicht vom "Industriestandard", sondern vom heutzutage präferierten Mittel. Und was hat JWT mit irgendetwas zu tun? Das ist einfach nur ein Format für's Token. Das kannst du auch mit OAuth2 verwenden. Du könntest es sogar als HTTP Session ID benutzen, wenn dir danach ist.

Im Endeffekt ist es aber auch relativ egal. Man schickt ja bloß seine (wie auch immer gearteten) Credentials (und evtl. Claims) an den Server. Ob man das jetzt mit jedem Request macht, oder als Austausch dafür ein Opaque Token bekommt, macht keinen Unterschied.

Dasselbe gilt für REST vs. SOAP vs. RPC vs. GraphQL vs. was auch immer. Schnittstelle ist Schnittstelle. Funktionsname, Parameter, Return Value. Ob der Funktionsname jetzt in der URL enthalten ist, oder Teil eines XML Dokuments, oder per RPC direkt angesprochen wird, ist doch Jacke wie Hose.

 

[ayngush]

Das heutzutage präferierte Mittel ist nicht OAuth2, das ist lediglich ein Authentifikationsprotokoll, welches neben eigenen Implementationen mittels JWT, einfacher API-Key Implementation, x.509 Austausch, uvm. auch, hauptsächlich bei öffentlichen APIs, Verwendung findet und da ein quasi Standard ist. In industriellen Anwendungen ist der Aufwand manchmal zu komplex und wenn dort kein Schlüsselaustauschproblem besteht, kann man auf dieses komplexe Protokoll mit der entsprechenden Infrastruktur verzichten, was dann auch häufig getan wird.

Ist das so verständlicher?

Und REST-APIs, die am weitesten verbreitet sind, sind per Design Zustandslos, deswegen gibt es da per Definition keine wie auch immer gearteten Sitzungen. Und deswegen auch keine wie auch immer gearteten Sitzungskennzeichen (HTTP Session ID).

Edit: zum Thema "Auth-Standard"... ich durfte (musste) letztens so etwas implementieren:

POST-Variable

systemId
brokerId
callbackUrl (falls gewünscht)
hashCode Prüfsumme für sichere Kommunikation Ja
...

Prüfsumme
Die Prüfsumme stellt sicher, dass bei Kenntnis des Links nicht automatisch Links von anderen Maklern
generiert werden können und wird wie folgt gebildet:

Codebeispiel PHP:
define('PREFIX', 'abc');
define('SUFFIX', 'defg');
$maklerId = '123';
$pruefsumme= substr(hash('sha512',PREFIX. $maklerId .SUFFIX), 0, 10);

Und das ist kein Witz. Das ist eine recht moderne und neu aufgesetzte Plattform für einen spezifische Bereich im Versicherungs-Geschäftsfeld von so einem "Insuretech" Startup.

Gut, dass es Standards gibt. Traurig, dass sich nicht alle daran halten

 

[benneq]

Ist das so verständlicher?

Ja, das passt. Aber ändert nichts daran, dass es vollkommen egal ist. Also API Consumer nutzt man halt einfach das, was angeboten wird - gezwungenermaßen.

Und REST-APIs, die am weitesten verbreitet sind, sind per Design Zustandslos, deswegen gibt es da per Definition keine wie auch immer gearteten Sitzungen. Und deswegen auch keine wie auch immer gearteten Sitzungskennzeichen (HTTP Session ID).

Zustandslosigkeit ist natürlich eine schöne Sache. Und ist für eine RESTful API eine Voraussetzung. Bringt dir aber als Client auch nichts, wenn deine präferierte API das nicht anbietet. Ich habe immer noch gelegentlich mit Business APIs zu tun, die nicht einheitlich arbeiten und/oder auf HTTP Sessions setzen.

Wie oben schon gesagt: Für den API Consumer spielt das alles keine Rolle. Man ist ja eh gezwungen zu nutzen, was angeboten wird. Und wenn die API ein Cookie für die Authentifizierung nutzt, dann bau ich meinen Client halt so, dass er ein Cookie sendet statt einem Authorization Header. Im Endeffekt ist ja eh nur ein Opaque Token in irgendeiner Form und muss irgendwie übertragen werden.

 

[ChilliSchotte]

Für den API Consumer spielt das alles keine Rolle. Man ist ja eh gezwungen zu nutzen, was angeboten wird. Und wenn die API ein Cookie für die Authentifizierung nutzt, dann bau ich meinen Client halt so, dass er ein Cookie sendet statt einem Authorization Header.

Vollkommen richtig, eine Schnittstelle ist im allerersten Step aus Consumersicht ja nichts anderes als ein Bedarf, der Bedarf an Daten zu kommen ohne diese händisch zu übertragen für whatever/whenever. Was es ist entscheidet leider der Anbieter der Schnittstelle, leider auch dann wenn Portale mit "hochautomatisierter Artikelpflege via Schnittstelle" werben und letztenendes kommt dann die ernüchterung mittels input/file .csv

 

[ayngush]

Deswegen lernt man es halt von Anfang an richtig, damit wir alle dann irgendwann nicht mehr so oft mit irgendwelchen Pseudeo-Standards und schrecklichen Schnittstellen zu tun haben. An den von mir geposteten kurzen Auszug einer Schnittstellenbeschreibung oben sieht man ja, dass selbst StartUps, die neue Plattformen schaffen es vor zwei drei Jahren nicht richtig hinbekommen haben eine ordentlichen REST-API für ihren Webservice zu bauen, sondern irgendwas zusammen geschustert haben, was jetzt halt so läuft und den Kunden angeboten wird. Wäre da jemand jedoch in Sachen REST API und gängigen Standards bezüglich Authentification und Authorisation fit gewesen, dann wäre deren Schnittstelle besser geworden und ich hätte nicht so viele Kopf- und Bauchschmerzen bei der Implementierung und unsere Systeme behabt, weil ich ständig vor Lachen den Kopf auf den Tisch fallen ließ...

 

[benneq]

weil ich ständig vor Lachen den Kopf auf den Tisch fallen ließ...

... Stichwort: Fachkräftemangel in Deutschland

 

[ayngush]

Das ist eher so ein Ding von "schnell und günstig". Ich habe es in der gleichen Branche ja ebenfalls mit der trusted german insurance cloud (TGIC) zu tun, dessen generelle Infrastruktur von IBM entwickelt und auf fröhlichen round about 1000 Seiten dokumentiert wurde. Inklusive des insurance security token service (ISTS) für Authentification. Leider ist das im Webservice-Bereich dann so ein SOAP / SAML Monster. Aber insgesamt eine schön komplex aufgebaute Community Cloud nach allen Regeln der (Java-)Kunst. Hat auch garantiert ne Mark fünfzig gekostet und Jeder Change zieht einen Aufwand von Mannjahren nach sich oder so... Hat halt alles seine Vor- und Nachteile. Geht aber halt so oder so. Und ja: Fachkräftemangel. Zeitmangel. Mangel an sämtlichen Resourcen. Wissensrückstand. Keine Ahnung, was dazu führt, dass man $pruefsumme= substr(hash('sha512',PREFIX. $maklerId .SUFFIX), 0, 10); macht...