REST APIs liegen im Trend und werden daher in vielen Projekten eingesetzt. REST besitzt Schwächen, die bei falschem Einsatz schnell sichtbar werden. Dieser Vortrag zeigt die Probleme und Schächen von REST und beschreibt die Alternativen: GraphQL, JSON Path und GRPC.
Speaker: Sven Kölpin
Komponentenbibliotheken wie Primefaces und Richfaces stellen für die Entwicklung von JSF-Anwendungen eine Vielzahl komplexer Komponenten bereit. Aber der ersten Euphorie folgt die Ernüchterung. Und statt der erhofften Vorteile muss man sich mit neuen Problemen befassen. Dabei kann man sich mit HTML5, JavaScript, Composite Components und der Behavior API maßgeschneiderte Erweiterungen für die eigene Anwendung schaffen.
Der Vortrag zeigt wie man für eine JSF-Anwendung dynamische und wiederverwendbare Bausteine für die eigene Anwendung realisieren kann.
Dass eine Anwendung gegen Angriffe von Außen abgesichert werden muss, ist in der heutigen Zeit keine Frage mehr. Die OWASP Top10 sind in aller Munde. Um so verwunderlicher ist es, dass in den meisten Projekten die Suche nach Sicherheitslücken frühestens nach Fertigstellung der Software angegangen wird. Dabei gibt es ein paar Möglichkeiten, bekannte Security-Probleme bereits während der Entwicklung automatisiert zu erkennen und dem Entwickler so durch geeignetes Feedback die Möglichkeit zu geben, diese zeitnah zu beheben.
In dem Talk werden verschiedene Tools vorgestellt und gezeigt, welche Security-Probleme schon während der Entwicklung durch Continous Integration vermieden werden können.
17 years after Fieldings paper REST is at its peak. Every interface has to use REST. But there are many problems in using and designing REST APIs. This sessions describes the problems and encourages to use besides REST other means of communication.
Im Kontext von APIs kommt derzeit keiner an REST (Representational State Transfer) vorbei. REST gilt als leichtgewichtige, skalierbare und schnell erlernbare Alternative zu SOAP, die sich die vorhandene Infrastruktur des WWW zunutze macht. In der Praxis hat aber auch REST seine Schwächen. So ist gutes API-Design häufig eine Herausforderung. Für mobile Anwendungen ist REST zu starr und geht nicht effizient genug mit Bandbreite um.
Im Vortrag werden Stärken und Schwächen von REST aufgezeigt und mit GraphQL eine Alternative speziell für den mobilen Kontext vorgestellt.
Wir haben im Rahmen des siebenten Magento-Stammtischs Wien unsere Erfahrungen aus unserem letzten Magento-Enterprise-Projekt geteilt.
In der Präsentation geben wir Tipps zu den Themen Projektübernahme, Verwaltung der Aufgaben, 3rd-Party-Extensions, Geotargeting, Bestellungsabwicklung, Backend-Anpassungen, Verwaltung mehrerer Entwicklungsumgebungen und Monitoring.
Speaker: Sven Kölpin
Komponentenbibliotheken wie Primefaces und Richfaces stellen für die Entwicklung von JSF-Anwendungen eine Vielzahl komplexer Komponenten bereit. Aber der ersten Euphorie folgt die Ernüchterung. Und statt der erhofften Vorteile muss man sich mit neuen Problemen befassen. Dabei kann man sich mit HTML5, JavaScript, Composite Components und der Behavior API maßgeschneiderte Erweiterungen für die eigene Anwendung schaffen.
Der Vortrag zeigt wie man für eine JSF-Anwendung dynamische und wiederverwendbare Bausteine für die eigene Anwendung realisieren kann.
Dass eine Anwendung gegen Angriffe von Außen abgesichert werden muss, ist in der heutigen Zeit keine Frage mehr. Die OWASP Top10 sind in aller Munde. Um so verwunderlicher ist es, dass in den meisten Projekten die Suche nach Sicherheitslücken frühestens nach Fertigstellung der Software angegangen wird. Dabei gibt es ein paar Möglichkeiten, bekannte Security-Probleme bereits während der Entwicklung automatisiert zu erkennen und dem Entwickler so durch geeignetes Feedback die Möglichkeit zu geben, diese zeitnah zu beheben.
In dem Talk werden verschiedene Tools vorgestellt und gezeigt, welche Security-Probleme schon während der Entwicklung durch Continous Integration vermieden werden können.
17 years after Fieldings paper REST is at its peak. Every interface has to use REST. But there are many problems in using and designing REST APIs. This sessions describes the problems and encourages to use besides REST other means of communication.
Im Kontext von APIs kommt derzeit keiner an REST (Representational State Transfer) vorbei. REST gilt als leichtgewichtige, skalierbare und schnell erlernbare Alternative zu SOAP, die sich die vorhandene Infrastruktur des WWW zunutze macht. In der Praxis hat aber auch REST seine Schwächen. So ist gutes API-Design häufig eine Herausforderung. Für mobile Anwendungen ist REST zu starr und geht nicht effizient genug mit Bandbreite um.
Im Vortrag werden Stärken und Schwächen von REST aufgezeigt und mit GraphQL eine Alternative speziell für den mobilen Kontext vorgestellt.
Wir haben im Rahmen des siebenten Magento-Stammtischs Wien unsere Erfahrungen aus unserem letzten Magento-Enterprise-Projekt geteilt.
In der Präsentation geben wir Tipps zu den Themen Projektübernahme, Verwaltung der Aufgaben, 3rd-Party-Extensions, Geotargeting, Bestellungsabwicklung, Backend-Anpassungen, Verwaltung mehrerer Entwicklungsumgebungen und Monitoring.
Api Platform: the ultimate API PlatformStefan Adolf
Unzählige Tools in allen Sprachen unterstützen einen dabei, solide APIs zu bauen, aber die Symfony-basierte api-platform sticht hervor: mit ihr erstellt man OpenAPI-kompatible REST-Schnittstellen nur mit Hilfe von einfachen Code-Annotationen. Stefan präsentiert zunächst die Basisinstallation des Frameworks und stellt seine wichtigsten Features vor, um dann tiefer in produktive Details einzusteigen. Darunter, wie man Client-Code und SPA-Frontends automatisch generiert, datenbankbasierte Akzeptanztests in Behat und Mink schreibt, sich per JWT authentifiziert, Custom Endpoints erstellt und von Doctrine ORM unabhängige Datenquellen nutzt. Schließlich demonstriert er, wie sich die produktive Vue.js-SPA seines Projekts via Apollo-Client mit automatisch generierten GraphQL-Endpunkten verbindet, ohne einen einzigen Resolver schreiben zu müssen und wie das brandneue Mercure-Protokoll dafür sorgt, dass das Frontend automatisch mitbekommt, wenn sich Daten auf dem Server ändern.
Echtzeitvisualisierung von Twitter & CoOliver Lemm
The presentation was hold on APEX Connect 2016 in Berlin 26th of april together with Kai Donato. It demonstrates how to use the Twitter streaming api and visualize it by realtime in a graph using VivagraphJS.
Folien zu unserem Vortrag beim Java Forum Stuttgart 2014
Besuchen Sie uns unter http://www.thecodecampus.de
Müssen Sie auch noch alte servergetriebene Java-Webanwendungen weiterentwickeln und wollen Ihre Kunden dabei den Genuss der Usability moderner Webseiten bieten?
In unserem Talk beim JavaForum Stuttgart 2014 haben wir anhand von Codebeispielen und Erfahrungsberichten gezeigt wie man schrittweise AngularJS in bestehende Anwendungen integriert. Dieser agile Ansatz liefert schnelle Ergebnisse und reduziert die Kosten und Risiken im Vergleich zu einer kompletten Umstellung.
OSMC 2012 | End2End-Monitoring von Webapplikationen mit SAHI by Simon MeggleNETWAYS
Bei modernen Web-Anwendungen sollten nicht nur die am Ergebnis beteiligten Komponenten aus technischer Sicht, sondern auch das Ergebnis aus der Warte des Anwenders überwacht werden.
Mit dem Open-Source-Tool SAHI lassen sich umfangreiche End2End-Checks für Web2.0-Applikationen schnell und komfortabel aufzeichnen und automatisiert abspielen. In diesem Vortrag wird gezeigt, wie SAHI-Tests in ein Nagios-kompatibles Monitoring-System integriert werden können. Ergänzt werden die Checks durch Zeitmessungen für Teilschritte, die Visualisierung der Laufzeiten in RRD-Graphen sowie die automatische Erstellung von Screenshots zur Fehleranalyse.
JSF 2.x hat mit einem verbesserten GET-Support und View-Parametern inzwischen schon einiges zum Thema RESTful zu bieten. Das Open-Source-Projekt PrettyFaces geht noch einen Schritt weiter, in dem es erlaubt, fast beliebige RESTful URLs zu erzeugen. Zudem bietet PrettyFaces noch weitere hilfreiche Goodies. In dieser Session wird auf die Konfiguration und die Verwendung von PrettyFaces im Detail eingegangen und aufgezeigt, wie sich zudem ganz einfach die SEO-Eigenschaften (Search Engine Optimization) der Applikation verbessern lassen.
20161123_API Summit:
Denk man an Web APIs, dann verbindet man das zugehörige Kommunikationsmodell meist mit RESTful Requests & Responses. Dies macht in vielen Fällen sicherlich auch Sinn. Aber eben nicht in allen! Was ist z. B., wenn auf Seiten des Clients komplexe Abfragen anstehen, die sich nicht so einfach über simple “Ressourcen” abbilden lassen. Wie geht man damit um, wenn auf dem Server lang laufende Aktionen angestoßen werden, auf deren Abarbeitung der Client nicht unbedingt warten möchte? Und muss es eigentlich immer clientseitiges “Pull” sein oder macht nicht Serverseitiges “Push” via Websockets in vielen Anwendungsfällen mehr Sinn? Die Session zeigt anhand ausgewählter, praxisnaher Use-Cases, wie man durch verschiedene Pattern das klassische RESTful Request-/Response-Modell seiner Web API sinnvoll erweitern kann und so zu deutlich eleganteren und performanteren Lösungen kommt.
Hands-on Workshop: API-Dokumentation mit OpenAPI / Swagger in ASP.NET CoreGregor Biswanger
Das Dokumentieren einer API wird oft als mühsame, aber wesentliche Aufgabe angesehen. Mit OpenAPI / Swagger können wir eine API-Dokumentation angenehm einfach in ASP.NET Core integrieren. Gregor Biswanger zeigt, wie eine API-Dokumentation mit einer Benutzeroberfläche hinzugefügt wird, mit der wir die API testen können.
Als Nächstes erfahren wir, wie wir Attribute und Konventionen verwenden, um die generierte OpenAPI-Spezifikation zu verbessern. Abschließend wird gezeigt, wie wir mit der Authentifizierung, Versionierung und Anpassung der Benutzeroberfläche umgehen.
Api Platform: the ultimate API PlatformStefan Adolf
Unzählige Tools in allen Sprachen unterstützen einen dabei, solide APIs zu bauen, aber die Symfony-basierte api-platform sticht hervor: mit ihr erstellt man OpenAPI-kompatible REST-Schnittstellen nur mit Hilfe von einfachen Code-Annotationen. Stefan präsentiert zunächst die Basisinstallation des Frameworks und stellt seine wichtigsten Features vor, um dann tiefer in produktive Details einzusteigen. Darunter, wie man Client-Code und SPA-Frontends automatisch generiert, datenbankbasierte Akzeptanztests in Behat und Mink schreibt, sich per JWT authentifiziert, Custom Endpoints erstellt und von Doctrine ORM unabhängige Datenquellen nutzt. Schließlich demonstriert er, wie sich die produktive Vue.js-SPA seines Projekts via Apollo-Client mit automatisch generierten GraphQL-Endpunkten verbindet, ohne einen einzigen Resolver schreiben zu müssen und wie das brandneue Mercure-Protokoll dafür sorgt, dass das Frontend automatisch mitbekommt, wenn sich Daten auf dem Server ändern.
Echtzeitvisualisierung von Twitter & CoOliver Lemm
The presentation was hold on APEX Connect 2016 in Berlin 26th of april together with Kai Donato. It demonstrates how to use the Twitter streaming api and visualize it by realtime in a graph using VivagraphJS.
Folien zu unserem Vortrag beim Java Forum Stuttgart 2014
Besuchen Sie uns unter http://www.thecodecampus.de
Müssen Sie auch noch alte servergetriebene Java-Webanwendungen weiterentwickeln und wollen Ihre Kunden dabei den Genuss der Usability moderner Webseiten bieten?
In unserem Talk beim JavaForum Stuttgart 2014 haben wir anhand von Codebeispielen und Erfahrungsberichten gezeigt wie man schrittweise AngularJS in bestehende Anwendungen integriert. Dieser agile Ansatz liefert schnelle Ergebnisse und reduziert die Kosten und Risiken im Vergleich zu einer kompletten Umstellung.
OSMC 2012 | End2End-Monitoring von Webapplikationen mit SAHI by Simon MeggleNETWAYS
Bei modernen Web-Anwendungen sollten nicht nur die am Ergebnis beteiligten Komponenten aus technischer Sicht, sondern auch das Ergebnis aus der Warte des Anwenders überwacht werden.
Mit dem Open-Source-Tool SAHI lassen sich umfangreiche End2End-Checks für Web2.0-Applikationen schnell und komfortabel aufzeichnen und automatisiert abspielen. In diesem Vortrag wird gezeigt, wie SAHI-Tests in ein Nagios-kompatibles Monitoring-System integriert werden können. Ergänzt werden die Checks durch Zeitmessungen für Teilschritte, die Visualisierung der Laufzeiten in RRD-Graphen sowie die automatische Erstellung von Screenshots zur Fehleranalyse.
JSF 2.x hat mit einem verbesserten GET-Support und View-Parametern inzwischen schon einiges zum Thema RESTful zu bieten. Das Open-Source-Projekt PrettyFaces geht noch einen Schritt weiter, in dem es erlaubt, fast beliebige RESTful URLs zu erzeugen. Zudem bietet PrettyFaces noch weitere hilfreiche Goodies. In dieser Session wird auf die Konfiguration und die Verwendung von PrettyFaces im Detail eingegangen und aufgezeigt, wie sich zudem ganz einfach die SEO-Eigenschaften (Search Engine Optimization) der Applikation verbessern lassen.
20161123_API Summit:
Denk man an Web APIs, dann verbindet man das zugehörige Kommunikationsmodell meist mit RESTful Requests & Responses. Dies macht in vielen Fällen sicherlich auch Sinn. Aber eben nicht in allen! Was ist z. B., wenn auf Seiten des Clients komplexe Abfragen anstehen, die sich nicht so einfach über simple “Ressourcen” abbilden lassen. Wie geht man damit um, wenn auf dem Server lang laufende Aktionen angestoßen werden, auf deren Abarbeitung der Client nicht unbedingt warten möchte? Und muss es eigentlich immer clientseitiges “Pull” sein oder macht nicht Serverseitiges “Push” via Websockets in vielen Anwendungsfällen mehr Sinn? Die Session zeigt anhand ausgewählter, praxisnaher Use-Cases, wie man durch verschiedene Pattern das klassische RESTful Request-/Response-Modell seiner Web API sinnvoll erweitern kann und so zu deutlich eleganteren und performanteren Lösungen kommt.
Hands-on Workshop: API-Dokumentation mit OpenAPI / Swagger in ASP.NET CoreGregor Biswanger
Das Dokumentieren einer API wird oft als mühsame, aber wesentliche Aufgabe angesehen. Mit OpenAPI / Swagger können wir eine API-Dokumentation angenehm einfach in ASP.NET Core integrieren. Gregor Biswanger zeigt, wie eine API-Dokumentation mit einer Benutzeroberfläche hinzugefügt wird, mit der wir die API testen können.
Als Nächstes erfahren wir, wie wir Attribute und Konventionen verwenden, um die generierte OpenAPI-Spezifikation zu verbessern. Abschließend wird gezeigt, wie wir mit der Authentifizierung, Versionierung und Anpassung der Benutzeroberfläche umgehen.
1. REST: Versprechen,
Wirklichkeit & die
Alternativen GraphQL,
gRPC, JSON RPC...
Version 1.2 vom 17.4.2017
Thomas Bayer
bayer@predic8.de
@thomasub
2. REST
#1 ist zu technisch
#2 ist kein Standard
#3 ist datengetrieben
#4 Design ist kompliziert
#5 fehlen Hypermedia Clients
#6 wird von Swagger bedroht!
9. REST
#1 ist zu technisch
#2 ist kein Standard
#3 ist datengetrieben
#4 Design ist kompliziert
#5 fehlen Hypermedia Clients
#6 wird von Swagger bedroht!
28. REST
#1 ist zu technisch
#2 ist kein Standard
#3 ist datengetrieben
#4 Design ist kompliziert
#5 fehlen Hypermedia Clients
#6 wird von Swagger bedroht!
30. POST /produkte/
PUT /produkte/65
PATCH /produkte/65
Resource GET POST PUT DELETE
/articles/ List aller Artikel 201 Created
Neuer Artikel
erzeugen*
Location
Header setzen!
400 Bad
Request
Alle Artikel
löschen
/articles/7 Details zu
einem Artikel
400 Bad
Request
Artikel
erzeugen* oder
ändern
Artikel löschen
?
34. Prozesse &
Nicht-Ressource Anfragen
Ressourcen passen irgendwie nicht richtig oder sind uninteressant
Beispiele
Errechnen
Umwandeln
Prozess als Ressource oft umständlich
/order/4/actions/cancel
/antrag/4354/freigabe
/calculator/compute
35. REST Design Probleme
Mehrere Lösungen für ein Problem
REST ist nicht einfach, wenn die Aufgaben größer werden
Styleguide ist notwenig
Auswahl & Erstellung sind schwer
Es gibt keinen perfekten Styleguide
Auswirkung vieler Designentscheidungen nicht sofort erkennbar!
Viel Interpretation und Kreativität ist gefordert
Man beschäftigt sich mehr mit der Auslegung von REST als mit der
Fachlichkeit
Welches REST API hat ein gutes Design?
36. API Design: The Musical
Quelle: https://events.drupal.org/losangeles2015/sessions/api-design-musical
Play
57. Wer URIs dokumentiert macht RPC!
Fixe URIs führen zu starker Kopllung!
Mediatypes erfordern Dokumentation
Fielding, Kapitel 5!
58. Contract First mit Swagger
Swagger
mvn deploy
MVN
client.jar
Dependency
call
Projekt wird nur
gebaut. Kein
eigener Code
notwendig.
Code
Generation
Server Stub wird um
die Implementierung
erweitert
Client
59.
60.
61. • Das Remoting ist komplett
verborgen
• RPC sieht genauso aus
81. Chunky or Chatty?
Over Fetching
Mehr Daten als notwendig werden übertragen
=> Chunky
Under Fetching
Nicht genug Daten werden übertragen
• => Subressourcen oder Relationen müssen verfolgt werden
• => Chatty
Quelle:
• https://pixabay.com/de/blabla-tafel-belanglosigkeit-1432922/
• https://pixabay.com/de/katze-dunkel-kaffee-faul-liegen-1351612/
87. GRPC
RPC Framework
Basiert auf Google Protocol Buffers
Verwendet IDL
Protocol Buffers als Message Format
• JSON ist auch möglich
Art neues CORBA
HTTP/2 Transport
Geeignet für Mobile
Google stellt auf GRPC für Microservices um
Features
Streaming
Sprachunterstützung
Android, C++,C#, Go, Java, Node, Objective-C, PHP, Python, Ruby
Quelle
https://grpc.io
94. „The REST interface is designed to be efficient for large-
grain hypermedia data transfer, optimizing for the
common case of the Web, but resulting in an interface that
is not optimal for other forms of architectural
interaction.“
Quelle: https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
Fielding in 5.1.5 Uniform Interface
99. Quellen
Architectural Styles and the Design of Network-based Software
Architectures, Roy Thomas Fielding
https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
RFC 7230, Hypertext Transfer Protocol (HTTP/1.1): Message
Syntax and Routing
https://tools.ietf.org/html/rfc7230
RFC 7231, Hypertext Transfer Protocol (HTTP/1.1): Semantics and
Content
https://tools.ietf.org/html/rfc7231
White House Web API Standards
https://github.com/WhiteHouse/api-standards
Haufe API Style Guide
https://github.com/Haufe-Lexware/api-style-guide
RESTful APIs, the big lie, Michael S. Mikowski
https://mmikowski.github.io/the_lie/
Status Dogs
https://httpstatusdogs.com/
Hinweis der Redaktion
Technik ist verborgen
Wir reden heute über REST API
Interfaces zw. Client und Server zw. Maschine und Maschine
Sollen Anwendungsentwickler oder Schnittstellendesigner die HTTP Spec auswendig lernen?
2000
Kapitel 5: REST
Kapitel 6: Probleme bei REST auf HTTP übertragen
Steht alles was ich wissen muss, wenn ich REST richtig mache!
In den Köpfen ist POST zum Anlegen
Ich habs Probiert idempotentes Anlegen mit PUT wird nicht akzeptiert und führt immer wieder zu Diskussion
Erfahrung der Kommunity und Beispiele in Produkten.
Auslegung: Relgion
Notwendig, zum Teil wiedersprüchlich
Welche Methode, Wie Life-Cycle?
REST ist nicht uniform!
Ab 5:28 abspielen!
Kunden wollen URIs modellieren, kein Interesse am Design der Daten
Alle einverstanden
Welche API verarbeitet links in Repräsentationen, die von Clients übergeben werden?
Von irgendwo kenne ich das
API Beschreibung von CORBA/Web Services
REST ist das verfolgen von Links
REST kann für Swagger nichts!
Hypermedia war nie lebendig
Nicht Messaging, aber da gibt es auch Alternativen
RPC Protokoll
Designed to be simple
Transport Agnostisch
HTTP, TCP, Memory
Positional & Named Parameters
Batches
Spezifikation
JSON-RPC 2.0 ( März 2010)
In 10 Minuten gelesen
Pfeil normal wagrecht, aber um Zeit zu illustrieren nach unten
Verzögerung spielt bei Mobile die größte Rolle
Pfeil normal wagrecht, aber um Zeit zu illustrieren nach unten
Verzögerung spielt bei Mobile die größte Rolle
Chattyhttps://pixabay.com/de/blabla-tafel-belanglosigkeit-1432922/