Einfach mal deployen reicht nicht, wenn es um Web-APIs geht: Man muss sicherstellen, dass das API wirklich tut, was sie soll. Und eine gute Dokumentation muss auch her! Sebastian Gingter zeigt in dieser Session von der BASTA! 2019, wie man dafür am besten vorgeht.
Damit ein Web-API erfolgreich ist, muss die Welt wissen, welche Funktionalität es bietet. Swagger aka OpenAPI ist ein Standard zur Beschreibung von Web-APIs, auf dem eine Vielzahl nützlicher Tools aufbaut.
Moderne verteilte Systeme im Web bestehen heutzutage aus vielen verschiedenen Teilen, Systemen und Technologien. Frontend und Backend sind zwei sehr wichtige Elemente einer aktuellen Webapplikation. Für maximale Flexibilität kann man diese Teile vollkommen trennen und eine im Browser laufende, eigene Applikation als Frontend mit einem REST-Service im Backend kommunizieren lassen.
Objektorientierte Programmierung hat ihre Vorteile, aber manchmal ist es schwierig, sich diese zunutze zu machen. Wer dann stur bei den Grundideen bleibt, der macht sich zusätzliche Arbeit!
Web-APIs haben sich durch ihre Leichtgewichtigkeit und einfache Umsetzbarkeit als Mittel zur Systemintegration durchgesetzt. Doch geht es wirklich so einfach? Anlässlich der API Conference sprachen wir mit dem erfahrenen Softwarearchitekten Thilo Frotscher über dieses spannende Thema.
APIfication und API-Management sind in aller Munde, insbesondere im Zusammenhang mit plattformbasierten Geschäftsmodellen. Außerdem werden APIs häufig, die Überschrift hat es vorweggenommen, als Turbo der Digitalisierung betrachtet. Doch was genau steckt hinter diesen Buzzwords, und wie verändern sich dadurch Geschäftsmodelle?
Wir sind bis vor einigen Jahren in Workshops und Coachings zum Thema REST im Architekturumfeld oft mit der Frage konfrontiert worden, weshalb es nicht so etwas Tolles wie WSDL im REST-Umfeld gibt. Diese Frage hat immer ein Kopfschütteln ausgelöst.
Der Browser kann mehr als nur ein bisschen HTML & CSS anzeigen. Zahlreiche Browser-APIs bieten heute Optionen, die weit über die klassischen Browser-Optionen hinausgehen. Batterie-Management, Location und mehr sind mit Browser-APIs zu steuern.
Heute gehen API Conference und International JavaScript Conference in London zu Ende. Wir blicken zurück auf eine spannende Konferenzwoche: Das Gehirn hacken, eine Standard-Library für JavaScript und Karten für APIs waren wichtige Themen in dieser Woche.
Ohne APIs wären viele moderne Services wohl nicht möglich, allerdings gibt es auch so manche Stolperfalle. Ein Blick auf die rechtlichen Rahmenbedingungen, die Beachtung finden sollten.
Mehr als fünfzehn Jahre nach seiner „Erfindung“ durch Roy Fielding scheint RESTful-API-Design aktueller denn je. Egal ob im Umfeld von Microservices oder bei der Öffnung bisher nur intern genutzter Systeme – REST wohin man schaut! Aber was genau ist eigentlich REST? Nur weil JSON oder XML Payload via HTTP an einen Server gesendet beziehungsweise von eben diesem empfangen wird, hat man es noch lange nicht mit einem RESTful API zu tun. Was genau zeichnet also eine REST-Schnittstelle aus? Und ab wann kann man sie als wirklich gelungen bezeichnen? Spätestens bei dieser Frage scheiden sich die Geister.
Denkt man an Web-APIs, dann verbindet man das zugehörige Kommunikationsmodell meist mit RESTful Requests und Responses. Dies ergibt in vielen Fällen sicherlich auch Sinn, aber eben nicht in allen! Lars Röwekamp zeigt in seiner Session von der API Confernece 2017 anhand ausgewählter praxisnaher Use Cases, wie man durch verschiedene Patterns das klassische RESTful Request-/Response-Modell seines Web-API sinnvoll erweitern kann, und so zu deutlich eleganteren und performanteren Lösungen kommt.
