Verteilte Anwendungen Teil 9: Representational State Transfer (REST) Teil 1
|
|
- Klaus Böhm
- vor 5 Jahren
- Abrufe
Transkript
1 Verteilte Anwendungen Teil 9: Representational State Transfer (REST) Teil
2 Literatur [9-1] Fielding, Roy Thomas: Architectural Styles and the Design of Network-based Software Architectures. [9-2] Fielding, R.T.; Taylor R. N.: Principled Design of the Modern Web Architecture. ACM Transactions on Internet Technology, Vol. 2, No. 2, May 2002, Pages htt ps:// [9-3] HTTP-Dedfinitionen: [9-4] HTTP/1.1: Semantics and Content [9-5] HTTP/1.1: Conditional Requests [9-6] Tikov, Stefan et a.: REST und HTTP. 3. Auflage, dpunkt,
3 Übersicht HTTP (Wiederholung) REST-Prinzipien Konsequenzen Namenswahl Realisierung von Ressourcen 3
4 Hypertext Transfer Protokoll (HTTP) HTTP 1.1 definiert in RFC 7230 bis 7238 HTTP/2 (2.0) definiert in RFC 7540 Benutzung von Port 80 oder einem Port, der in der URL angegeben ist Aufbau einer URI/URL XXX=YYY... Angabe des Protokolls, hier http Angabe des Rechners, meist www Angabe der SubDomain entfällt meist Nach dem? folgen Zusatzinformationen Zusatzinformationen 4
5 HTTP als Client/Server- und Server/Server-Protokoll Übliche Verwendung mit Browsern Client Server Verwendung zwischen Servern 5
6 Referenzen Ressource Uniform Resource Identifier (URI) Ressource = "Betriebsmittel" = Mit URI adressiertes Objekt mit Daten und/oder Code Beispiele für Ressourcen Datei mit HTML Datei mit PHP-Code Graphik-Datei (*.gif, *.jpeg) Ladbare Klasse oder Modul(!) target resource = Ressource, die am Ende nach (optionalen) Weiterleitungen angesprochen wird 6
7 HTTP-Request Header Request Line Header Fields Payload MIME-Header Message Kopf = Header = Block von Informationen über die Anforderungen bzw. Antwort Nachricht = Payload = Daten als Repräsentation der Ressource Repräsentation = Inhalt oder Teil der Ressource in einem bestimmten Format 7
8 Methoden der Request Line I Method URL HTTP-Version Methode Definierte/Intendierte Semantik GET HEAD POST PUT Es wird die aktuelle Repräsentation geladen Wie GET, aber nur der Header Operationen werden an der Ressource durchgeführt Die Ressource wird angelegt oder überschrieben DELETE Die Ressource wird gelöscht CONNECT Aufbau einer Verbindung zum Server OPTIONS Holen der Fähigkeiten des Servers TRACE Es wird die Verbindung zum Server getestet 8
9 Methoden der Request Line II Manchmal wird anstatt von Methoden von Verben gesprochen; es besteht sonst kein Unterschied. Wie später erkennbar wird, reichen für bestimmte Anwendungen die "offiziellen" Methoden nicht aus. Für WebDAV wurden weitere Methoden definiert: u.a. PATCH Siehe: 9
10 Beispiele für Header-Informationen (Request) Keyword Accept Authorization Cookie Cookie2 Erläuterung Vom Client angeforderte(s) Datenformat(e) "Benutzername:Password" in base64 kodiert Form: Name=Wert Cookie im RFC-2965-Format Als Authentisierung (mit dem Schlüsselwort Authorization) kann die Basic Access Authentication angewendet werden, z.b. konfiguriert über.htaccess-dateien beim Apache-Webserver. 10
11 HTTP-Response Header Status Line Header Fields Payload MIME-Header Message Kopf = Header = Block von Informationen über die Anforderungen bzw. Antwort Nachricht = Payload = Daten als Repräsentation der Ressource Repräsentation = Inhalt oder Teil der Ressource in einem bestimmten Format 11
12 I Mit der Site web-sniffer.net können leicht die HTTP-Pakete visualisiert werden. Das geht auch lokal mit Sniffern wie wireshark. 12
13 II 13
14 Verbreitung von API-Protokollen (2010) new-job-requirement-experience-building-restful-apis/2010/06/09 14
15 SOAP/XML vs REST/JSON I SOAP-Version Beispiel aus 15
16 SOAP/XML vs REST/JSON II REST-Version Beispiel aus 16
17 Representation State Transfer (REST) - die Idee Client Ressource' Server Ressource Der Client fordert den Zustand einer Ressource an. Per HTTP wird dieser Zustand übertragen und im Client verarbeitet. Im Client und im Server befindet sich dann dieselbe Ressource in verschiedenen Zuständen. Übertragen wird immer die Repräsentation eines Zustands. Daher: Representation State Transfer (REST) 17
18 Dies stimmt nicht ganz... Es muss nicht (immer) der gesamte Zustand in den Client übertragen werden. Weiterhin setzt eine Ressource eine URI voraus und dies kann nur von einem Client in der Rolle eines Servers realisiert werden. Vereinfachend kann aber von einer Ressource im Klienten gesprochen werden. Dann noch etwas: Klient/Client bedeutet hier eine Maschine in der Rolle des Klienten Server bedeutet hier eine Maschine in der Rolle eines Servers Eine Maschine kann beide Rollen gleichzeitig einnehmen. 18
19 REST Prinzipien 1) Client-Server-Prinzip Nur vom Client geht der Anstoß einer Aktivität aus (Pull-Prinzip) 2) Zustandslos Der Client liefert alle Informationen mit jedem Request; es gibt im Server keinen Kontext (Sessions) bezogen auf die Kommunikation. 3) Einheitliche Schnittstelle Es werden als Operationen nur die HTTP-Methoden benutzt: GET, PUT, HEADER, POST, DELETE etc. 4) Namen von Ressourcen (URI) Jede Ressource hat eine eigene eindeutige URI. 5) Relationen zwischen Ressourcen durch URI Alle Beziehungen zwischen Ressourcen werden mit Hilfe von URIs ausgedrückt. Schnittstellen, die diesen Prinzipien genügen, werden RESTful genannt. 19
20 REST - Vorteile 1) Client-Server-Prinzip Verlagerung der Sitzungsinformation in den Client 2) Zustandslos Besseres Skalieren Gute Benutzung von Caches 3) Einheitliche Schnittstelle Einfachheit Theoretisch kann jede Applikation mit jeder anderen zusammenarbeiten 4) Namen von Ressourcen (URI) Universelles Namenskonzept mit eindeutigen Namen 5) Relationen zwischen Ressourcen durch URI Gute Kombinierbarkeit unterschiedlicher Anwendungen 20
21 Konsequenzen Einheitliche Schnittstelle I Methode Request Response Safe Idempotent Cacheable GET - Body Ja Ja Ja HEAD - - Ja Ja Ja POST Body Body Nein Nein?? PUT Body Body Nein Ja Nein DELETE - Body Nein Ja Nein CONNECT Body Body Nein Nein Nein OPTIONS - Body Ja Ja Nein TRACE - Body Ja Ja Nein Body bedeutet, dass eine Nachricht (Payload) im Paket vorhanden sein kann. Safe bedeutet, dass keine Zustandsänderungen an der Ressource vorgenommen werden. 21
22 Konsequenzen Einheitliche Schnittstelle II Idempotent = Keine Änderung der Semantik bei ein- oder mehrmaliger Ausführung derselben Operation Duplizierungen durch das Netzwerk verursachen hier keinen Schaden. Nach einem Wiederanlaufen können derartige Operationen jederzeit ausgeführt werden. Cacheable = Der Inhalt des Responses kann in einem Cache für ein späteres GET auf diese Ressource gehalten werden, sei es im Browser oder in einem dem Server vorgeschalteten Cache. Bei der POST-Methode ist das Abspeichern im Cache nicht so klar. Nach einem PUT kann es sinnvoll sein, den Inhalt im Cache zu halten, wenn nämlich durch das PUT der Zustand nicht verändert wurde, z.b. 2x dasselbe PUT auf dieselbe Ressource: dann kann das 2. PUT im Cache gehalten werden. 22
23 Bemerkungen für RESTful-APIs Die Tabelle gibt die Anforderungen an eine REST-API wieder, d.h. eine API muss diese Eigenschaften realisieren, um RESTful zu sein. In der Praxis gibt es modifizierende Operationen mit der GET- Methode, z.b. GET Das ist möglich, aber nicht RESTful. Die POST-Operation sollte vermieden werden, da diese keine allgemeinen Eigenschaften definiert. Viele RESTful-APIs sind gar nicht RESTful... 23
24 Konsequenzen Einheitliche Schnittstelle III Ressource: Methode Bedeutung GET PUT Abfrage des Zustands der Bestellung Neuanlegen einer Bestellung oder Ändern einer bestehenden Bestellung DELETE Löschen einer bestehenden Bestellung Es wird das CRUD-Prinzip realisiert: create() mit der PUT-Methode read() mit der GET-Methode update() bzw. write() mit der PUT-Methode delete() mit der DELETE-Methode Mehr Operationen gibt es nicht! Vor allem keine "versteckten" Operationen, wie in GET 24
25 Konsequenzen Einheitliche Schnittstelle IV Es werden also nur die Operationen am Objekt (Ressource) selbst angegeben, nicht deren darüber hinaus gehende Bedeutung. Beispiel der Bestellung (Variante 1): Methode Akivität GET PUT PUT Abfrage des Zustands Neuanlegen einer Bestellung Ändern einer bestehenden Bestellung DELETE Löschen Bedeutung Es wird ein Query in einer Datenbank gemacht, die Bestellung und der Bearbeitungsstatus geliefert. Eine Bestellung wird in der Datenbank angelegt und der Prozess der Bearbeitung angestoßen. Ein Teil der Bestellung wird geändert. Die Bestellung wird storniert. 25
26 Konsequenzen Einheitliche Schnittstelle V Es kann aber auch eine andere Bedeutung definiert werden. Beispiel der Bestellung (Variante 2): Methode Akivität GET PUT PUT Abfrage des Zustands Neuanlegen einer Bestellung Ändern einer bestehenden Bestellung DELETE Löschen Bedeutung Es wird ein Query in einer Datenbank gemacht und die Bestellung geliefert. Eine Bestellung wird in der Datenbank angelegt und der Prozess der Bearbeitung angestoßen. Dies wird abgelehnt. Die Bestellung wird archiviert. 26
27 Bemerkungen zum Stil Prozeduraler/Objekt-Orientierter Stil: Die unterschiedliche Semantik drückt sich durch unterschiedliche, differenzierte Namen der Operationen primär im Server aus, der die Semantik realisiert. Es gibt RPCs. REST-Stil: Die Semantik der Anwendung ist implizit; die HTTP-Methode beschreibt nicht das, was sie eigentlich tut, sondern bezieht sich auf die Änderung von Zuständen. Die Operation wird primär im Client ausgeführt. Es gibt keine RPCs, sondern nur eine Übertragung von fertig erstellten Zuständen. 27
28 Dies stimmt nicht ganz... So betrachtet würde der Server nur die Funktion des Abspeicherns und Lieferns von Ressourcen haben. Für statische Web-Seiten ist das vollkommen in Ordnung, aber für "richtige" Anwendungen nicht, denn es wird Kontext benötigt: Prüfung der Identität (Authentisierung) Prüfung von Autorisierungen (Single Sign On, SSO) Realisierung von Transaktionen... Auf diesen Kontext muss der Server zugreifen können. Damit die API RESTful wird, muss der Kontext selbst wiederum eine Ressource sein, deren URI der Client kennen muss, aber keinen Zugriff haben sollte bzw. darf. Um aber die Erlaubnis zum Zugriff auf die Kontext-Ressource prüfen zu können, ist eine kleine Session-Information nötig. 28
29 In der Praxis... wird häufig "geschummelt": Es werden Zusatzinformationen über die Operation beim Request mitgegeben oder sogar ganz offen ein RPC mit der PUT-Operation verbunden. Gründe: Bei den schreibenden Operationen gibt es häufig mehrere Möglichkeiten, aus denen durch Zusatz-Informationen gewählt wird. Diese gehen über ein PUT weit hinaus. Software-technisch hier vom Aspekt der Wartung her ist das reine REST eine Katastrophe, weil nicht die Semantik in der API ausgedrückt wird. Dies führt zu schwer verständlichen Code. 29
30 Namenswahl I Die Ressourcen sollten mit Substantiven bezeichnet werden, nicht mit Verben. Beispiele Modifizieren: PUT Nicht: PUT Nicht: PUT Löschen: DELETE Nicht: PUT Nicht: PUT Das folgende Beispiel ist eine Katastrophe: GET falsch falsch falsch denn der Crawler von Google würde die Ressource löschen Jedenfalls wenn er die Erlaubnis dazu hätte. 30
31 Namenswahl II - Templates URI-Template = Schablone zum Aufbau von URIs mit variablen Bereichen Beispiele Der Name in {} ist eine Variable, die durch aktuelle Werte ersetzt wird. Siehe:
32 Dateisysteme sind ein bisschen RESTful Alle Dateien haben einen (einheitlich aufgebauten) Namen, z.b. /etc/ntp.conf Auf allen Dateien gibt es nur einen festen Satz von Operationen: Z.B. UNIX: open() read() write() seek() close() Auch die Permissions sind einheitlich: read, write Execute für Owner, Group und World Aber was die Operationen wirklich bedeuten, ist dem Betriebssystem unbekannt. 32
33 Arten von Ressourcen I Ressourcen oder Primärressourcen Typische URI: Subressourcen als Teil anderer Ressourcen Typische URI: Beispiele Bestandteile eines Dokuments Liste der Gegenstände einer Bestellung Listenressourcen als Zusammenfassung anderer Ressourcen Typische URI: Filter (Auszüge aus Listen) Typische URI: Paginierung (Aufteilen von Listen) Typische URI: 33
34 Arten von Ressourcen II Projektionen Ressource, die aus Teilen einer anderen besteht Aggregationen Zusammenfassung von Teilen verschiedener Ressourcen Aus der Sicht von REST besteht eine URI einer Ressource aus dem gesamten String der URI unabhängig vom Aufbau. Das? in der URI wird also nicht besonders beachtet. 34
35 Realisierung von Ressourcen Eine Ressource kann als Datei realisiert werden. Dies ist der Normalfall im Web., z.b. Die Dateitypenangaben (.jpg,.png,.html etc.) werden häufig weggelassen; dann aber müssen die URIs im Request durch den Server umgeschrieben werden, so dass intern wieder mit Endungen gearbeitet wird. Eine Ressource kann aber auch durch Zeilen in Tabellen einer relationalen Datenbank realisiert werden. Dann muss durch Umschreiben der URI der Code zum Zugriff auf die Datenbank angesprochen werden. Das geht natürlich auch mit NoSQL-Datenbanken. Siehe:
36 Verknüpfung von Ressourcen I {..., "links":{ }... Symbolischer Name URI dazu "all": " "employees": " "dismissed": " "retired": " }, Verknüpfungen erfolgen grundsätzlich über URIs. Verknüpfungen können symbolisch benannt werden, um durch den höheren Abstraktionsgrad Unabhängigkeit zu erreichen. Im Client werden die symbolischen Bezeichnungen zu URIs gemacht und benutzt. 36
37 Verknüpfung von Ressourcen II {..., "links":{ "person": " "file": " "note": " "finished": " },... } Listenressourcen können andere unter einem Aspekt zusammen fassen, z.b. Vorgänge in der Verwaltung bzw. im Workflow Management. Wenn in URIs Templates verwendet werden, so muss dies dem Client mitgeteilt werden bzw. von der API her vorgesehen sein. Am besten sind "sich selbstbeschreibende" Ressourcen, die also explizit angeben, ob die URIs Templates sind. 37
38 Verknüpfung von Ressourcen III {..., "links":{ "create": " "deactivate":" "rename": " "archive": " },... } Es sind auch Verzeichnisse von Operationen möglich. Dabei muss die Methode hier im Beispiel immer PUT klar sein. Dasselbe gilt auch für die Formate der JSON-Informationen, die dem PUT mitgegeben werden müssen. Dies ist aber eigentlich nicht RESTful. 38
39 Definition der Schnittstellen I Da bei REST sehr viele Information implizit sind, sollte die API syntaktisch vollständig als Ressource selbst definiert sein. Denn dann kann ein beliebiger Klient die Schnittstelle syntaktisch korrekt bedienen. Semantisch sieht es anders aus. Verfahren: 1)Der Klient holt sich die API-Definitions-Ressource 2)Anhand eines standardisierten Katalogs wird die Operation samt URI bestimmt. 3)Parameterliste bzw. Formate der Ressourcen werden gelesen, 4)entsprechend werden die Requests konstruiert, 5)und entsprechend werden die Responses interpretiert. 39
40 Definition der Schnittstellen II - Definitionen Beispiele für API-Definitionssprachen: Hypertext Application Language (HAL) basierend auf JSON RAML basierend auf YAML Zu YAML: SIREN basierend auf JSON
41 Versionen von Schnittstellen I Schnittstellen sollten konstant und langlebig sein. Dies gilt besonders für REST, da im Falle einer Änderung der API sehr viele Referenzen vor allem in den Ressourcen geändert werden müssen. Der nachhaltige Entwurf von APIs aber nicht einfach. Er ist genau das Gegenteil zu agilen Techniken. Siehe Pragmatisch wird eine Versionsnummer in die URIs eingebaut: XXX=YYY... Z.B. v1 in 41
42 Versionen von Schnittstellen II Die Frage ist, wann alte Schnittstellen entfernt werden können. Eigentlich nie... Also: Der Entwurf von REST-APIs ist immer langfristig auszurichten. 42
43 Nach dieser Anstrengung etwas Entspannung... 43
Stefan Tilkov. REST und HTTP. Einsatz der Architektur des Web für Integrationsszenarien. dpunkt.verlag
Stefan Tilkov REST und HTTP Einsatz der Architektur des Web für Integrationsszenarien dpunkt.verlag ~ы\ 1 Einleitung 1 1.1 Warum REST? 1 1.1.1 Lose Kopplung 2 1.1.2 Interoperabilität 2 1.1.3 Wiederverwendung
MehrArchitektur von REST basierten Webservices
28.11.2005 Architektur von REST basierten Webservices Referent MARK ALTHOFF REST was invented by ROY T. FIELDING and RICHARD N. TAYLOR Geschichtlicher Hintergrund von REST 1994-1995 taucht der Begriff
Mehr2. WWW-Protokolle und -Formate
2. WWW-Protokolle und -Formate Inhalt: HTTP, allgemeiner syntaktischer Aufbau Wichtige Methoden des HTTP-Protokolls Aufbau von Web-Applikationen unter Nutzung von HTTP, HTML, DOM XML, XML-DTD und XML-Schema
MehrBackend. Hochschule Darmstadt, Fachbereich Informatik, Wintersemester 2016/2017. Christopher Dörge, Thomas Sauer, David Müller
Backend Hochschule Darmstadt, Fachbereich Informatik, Wintersemester 2016/2017 Christopher Dörge, Thomas Sauer, David Müller Aufbau einer RESTful API mit... Ziel node.js, express und MongoDB Symfony und
MehrNetzwerke Teil 12: Hypertext Transfer Protokoll
Netzwerke Teil 12: Hypertext Transfer Protokoll 31.10.13 1 Literatur [12-1] Gourley, David; Totty, Brian: HTTP. The definitive Guide. O'Reilly, 2002 [12-2] Badach, Anatol; Rieger, Sebastian; Schmauch,
MehrWeb-Konzepte für das Internet der Dinge Ein Überblick
Web-Konzepte für das Internet der Dinge Ein Überblick Samuel Wieland sawielan@student.ethz.ch ETH Zürich Seminar Das Internet der Dinge Historisches Tim Berners-Lee Erster Web-Server Bildquelle: Wikimedia
MehrSODA. Die Datenbank als Document Store. Rainer Willems. Master Principal Sales Consultant Oracle Deutschland B.V. & Co. KG
SODA Die Datenbank als Document Store Rainer Willems Master Principal Sales Consultant Oracle Deutschland B.V. & Co. KG vs No Anforderungskonflikte Agile Entwicklung Häufige Schema-Änderungen Relationales
MehrRESTful API Grundlagen mit PHP und Payrexx
RESTful API Grundlagen mit PHP und Payrexx Autor: Michael Räss, michael.raess@payrexx.com Stand: 21.11.2017 Payrexx AG Ziele Begriffe und Definition verstehen Prinzipien / Funktionsweise kennenlernen Grundlagen
MehrWebtechnologien Teil 2: Hypertext Transfer Protokoll (Wiederholung aus Rechnernetze)
Webtechnologien Teil 2: Hypertext Transfer Protokoll (Wiederholung aus Rechnernetze) 03.10.16 1 Literatur [2-1] Gourley, David; Totty, Brian: HTTP. The definitive Guide. O'Reilly, 2002 [2-2] Badach, Anatol;
MehrEntwicklung einer REST-API zur Erstellung und Konfiguration von Microsoft Teams. Jan Kruse, utilitas GmbH
Entwicklung einer REST-API zur Erstellung und Konfiguration von Microsoft Teams Jan Kruse, utilitas GmbH 15.01.2018 Gliederung Einleitung Motivation Ziele Grundlagen ASP.Net Web API REST-API Microsoft
MehrVerteilte Anwendungen Teil 10: Representational State Transfer (REST) Teil 2
Verteilte Anwendungen Teil 10: Representational State Transfer (REST) Teil 2 24.05.18 1 Übersicht Neuanlegen von Ressourcen Ändern von Ressourcen 2 Die POST-Methode Die POST-Methode sollte möglichst vermieden
MehrVAADIN, SPRING BOOT & REST
VAADIN, SPRING BOOT & REST Ein Einstieg für Domino Entwickler Stephan Kopp 1 STEPHAN KOPP Software & Solutions Development Tel.: +49 6182 7869420 Mobil: +49 173 3089806 E-Mail: stephan.kopp@axians.de 2
MehrÜbersicht. Neuanlegen von Ressourcen Ändern von Ressourcen. VA SS Teil 10/REST2
Übersicht Neuanlegen von Ressourcen Ändern von Ressourcen 2 Die POST-Methode Die POST-Methode sollte möglichst vermieden werden, weil ihre Semantik nicht definiert ist, außer dass etwas geändert wird,
MehrODS 6.0 Schnittstelle
ODS 6.0 Schnittstelle Dieter Müller Server Developer 1 Architektur ODS-Schnittstelle Vergleich ODS 5.x ODS 6.0 ODS 5.x ODS 6.0 ODS Client ODS Server ODS Client ODS Server Stub ORB IIOP Generiert aus
Mehr!"#$"%&'()*$+()',!-+.'/',
Soziotechnische Informationssysteme 7. OAuth, OpenID und SAML Inhalte Motivation OAuth OpenID SAML 4(5,12316,7'.'0,!.80/6,9*$:'0+$.;.,&0$'0, 3, Grundlagen Schützenswerte Objekte Zugreifende Subjekte Authentifizierung!
Mehr<Insert Picture Here> Einführung in SOA
Einführung in SOA Markus Lohn Senior Principal Consultant SOA? - Ideen Selling Oracle To All SAP On ABAP Increasing Sales Of Applications 3 Agenda Motivation SOA-Definition SOA-Konzepte
MehrAnbindung an WebServices Robert Zacherl
Anbindung an WebServices Robert Zacherl WebServices Definition Wikipedia: Ein Webservice (auch Webdienst) ermöglicht die Maschine-zu-Maschine-Kommunikation auf Basis von HTTP oder HTTPS über Rechnernetze
MehrREST in Pieces. Jörn Clausen
REST in Pieces Jörn Clausen joern@techfak.uni-bielefeld.de Worum geht es? Dissertation Architectural Styles and the Design of Network-based Software Architectures von Roy T. Fielding, UC Irvine, 2000 [...
MehrLiteratur. [12-5] Upgrading to TLS Within HTTP/1.1 http://tools.ietf.org/html/rfc2817. Netzwerke - WS 2013/14 - Teil 12/HTTP
Literatur [12-1] Gourley, David; Totty, Brian: HTTP. The definitive Guide. O'Reilly, 2002 [12-2] Badach, Anatol; Rieger, Sebastian; Schmauch, Matthias: Web- Technologien. Hanser, 2003 [12-3] Hypertext
MehrREST Services in APEX Anwendungen nutzen
REST Services in APEX Anwendungen nutzen Carsten Czarski - @cczarski Consulting Member of technical Staff Oracle Application Express ORACLE Deutschland B.V. & Co KG REST: Representational State Transfer
MehrBUSINESSMAIL X.400 WEB SERVICE API MAILBOX STATUS V1.0
WEB SERVICE API MAILBOX STATUS V1.0 Gesicherte Kommunikation über Internet (https) für Kunden Web Service Client Anwendung https Internet TLS Proxy BusinessMail X.400 Application Server Web Service mit
MehrModul 9: Web APIs (REST, XHR, SSE, WebSockets)
Modul 9: Web APIs (REST, XHR, SSE, WebSockets) 10.06.2018 16:31:22 M. Leischner Internetkommunikation Folie 1 Anwendungsnähe Hochschule Browser Networking APIs, Protocols, and Services - Einordnung statisch
MehrNeue Welten: Externe Daten mit APEX nutzen
Neue Welten: Externe Daten mit APEX nutzen Carsten Czarski Oracle Application Express Development-Team DOAG Regio München - 17. Mai 2018 Copyright 2017 Oracle and/or its affiliates. All rights reserved.
MehrRESTful Web. Representational State Transfer
RESTful Web Representational State Transfer 1 Warum REST? REST ist die Lingua Franca des Webs Heterogene (verschiedenartige) Systeme können mit REST kommunizieren, unabhängig von Technologie der beteiligten
MehrHTTP. Arthur Zaczek. Aug 2015
Arthur Zaczek Aug 2015 1 Einleitung 1.1 Definition Das Hypertext Transfer Protocol (HTTP, dt. Hypertext-Übertragungsprotokoll) ist ein Protokoll zur Übertragung von Daten über ein Netzwerk. Es wird hauptsächlich
MehrREST in Pieces. Jörn Clausen joern@techfak.uni-bielefeld.de
REST in Pieces Jörn Clausen joern@techfak.uni-bielefeld.de Worum geht es? Dissertation Architectural Styles and the Design of Network-based Software Architectures von Roy T. Fielding, UC Irvine, 2000 [...
MehrGrundlagen der Web-Entwicklung INF3172
Grundlagen der Web-Entwicklung INF3172 Web-Services Thomas Walter 16.01.2014 Version 1.0 aktuelles 2 Webservice weitere grundlegende Architektur im Web: Webservice (Web-Dienst) Zusammenarbeit verschiedener
MehrGrundlagen Internet-Technologien INF3171
Fachbereich Informatik Informationsdienste Grundlagen Internet-Technologien INF3171 Cookies & Sessions Version 1.0 20.06.2016 aktuelles 2 Erweiterungen wir betrachten zwei Erweiterungen: Personalisierung
MehrRESTful API design. Warum REST mehr als HTTP mit XML ist. Dr. Stefan Schlott BeOne Stuttgart GmbH
RESTful API design Warum REST mehr als HTTP mit XML ist Don t get pissed by API design! Dr. Stefan Schlott BeOne Stuttgart GmbH Worum es gehen wird Was bestimme ich den Namen der URLs? Was ist Parameter?
MehrAnwendertreffen SWBcontent WLB Stuttgart. Renate Hannemann, Dr. Barbara Löhle, Stefan Wolf
Anwendertreffen SWBcontent 16.11.2011 WLB Stuttgart Renate Hannemann, Dr. Barbara Löhle, Stefan Wolf Inhalt Integration von Heritrix Qualitätssicherung bei der Migration der HTTrack Daten nach WARC 2 Integration
MehrAPIC-EM Software Engineering Insight
APIC-EM Software Engineering Insight Programmieren mit APIC-EM Fabian Wirz 8. September 2016 Fabian Wirz Informatikstudent Hochschule Rapperswil Faszination SDN und Cloud Computing Entwickler AnyMulticast
MehrGoogle Gears Offline Web?
Google Gears ist eine Browsererweiterung, die es in sich hat. Dem Webanwendungsentwickler werden Dienste bereitgestellt, die es ermöglichen, Webanwendungen so zu schreiben, dass eine Offline-Arbeit möglich
MehrREST Grundlagen. Seminar Aktuelle Software-Engineering-Praktiken für das World Wide Web. Olga Liskin <olga.liskin@gmail.com>
REST Grundlagen Seminar Aktuelle Software-Engineering-Praktiken für das World Wide Web Olga Liskin Übersicht Motivation, Einführung Architekturstil REST RESTful Webservices Patterns,
MehrHypertext Transfer Protocol
Ingo Blechschmidt LUGA 6. Juli 2005 Inhalt 1 Geschichte Verwendung von HTTP 2 Typischer Ablauf Request-Methoden Header-Felder Keep-Alive 3 Nutzen von Proxies Proxies bei HTTP CONNECT-Methode
MehrWeb APIs auf dem Prüfstand Volle Kontrolle oder fertig mit den Azure Mobile Services?
Web APIs auf dem Prüfstand Volle Kontrolle oder fertig mit den Azure Mobile Services? Web APIs Wo kommen wir her? Remote Procedure Calls (RPC) Verben/Aktionen im Endpunkt enthalten GetCustomer InsertInvoice
MehrWeb Grundlagen zum Spidering
May 22, 2009 Outline Adressierung 1 Adressierung 2 3 4 Uniform Resource Locator URL Jede Seite im Internet wird eindeutig über eine URL identiziert, z.b. http://www.christianherta.de/informationretrieval/index.html
MehrInhaltsverzeichnis. 2.1 Eine kurze Geschichte von REST... 9 2.2 Grundprinzipien... 11 2.3 Zusammenfassung... 17
xi 1 Einleitung 1 1.1 Warum REST?...................................... 1 1.1.1 Lose Kopplung................................ 2 1.1.2 Interoperabilität............................... 3 1.1.3 Wiederverwendung.............................
Mehr2.1 Eine kurze Geschichte von REST... 9 2.2 Grundprinzipien... 11 2.3 Zusammenfassung... 19
xiii 1 Einleitung 1 1.1 Warum REST?.......................................... 1 1.1.1 Lose Kopplung................................... 2 1.1.2 Interoperabilität.................................. 3 1.1.3
MehrPerl-Praxis. CGI-Skripte. Madis Rumming, Jan Krüger.
Perl-Praxis CGI-Skripte Madis Rumming, Jan Krüger {mrumming,jkrueger}@cebitec.uni-bielefeld.de Übersicht WWW, Web-Server CGI-Skripte Parameterübergabe Web-Formulare CGI.pm Perl-Praxis CGI-Skripte 2/16
MehrSeminararbeit. Konzept einer Schnittstelle zur Benutzerverwaltung in RiskShield-Server. Christoph Laufs INFORM GmbH INFORM GmbH 1
Seminararbeit Konzept einer Schnittstelle zur Benutzerverwaltung in RiskShield-Server Christoph Laufs INFORM GmbH 2016 - INFORM GmbH 1 Agenda 1. RiskShield-Server 2. Motivation und Anforderungen 3. Web
MehrLiteratur und Links. Webtechnologien SS 2017 Teil 1/Entwicklung
Literatur und Links [1-1] Seidler, Kai; Vogelsang, Kay: Das XAMPP Handbuch. Addison-Wesley, 2006 [1-2] http://www.apachefriends.org/download.html http://sourceforge.net/projects/xampp/files/ [1-3] http://aktuell.de.selfhtml.org/extras/download.shtml
MehrEine Untersuchung der Funktionen des Apache Wicket Webframeworks
Eine Untersuchung der Funktionen des Apache Wicket Webframeworks Seminararbeit von Olaf Matticzk 1 15.01.2016 (c) by synaix 2016 synaix...your business as a service. Agenda 1. Einleitung 2. Webanwendungen
MehrREST Services To-Go Einfacher Einstieg in die REST Programmierung
REST Services To-Go Einfacher Einstieg in die REST Programmierung 04.07.2017 Version 1.0 Seite 1 Zur Person Marcus Blum Oracle Forms seit 1994 (Forms 3 / Oracle 6 aufwärts) Fokus auf Oracle APEX seit 2007
MehrWebtechnologien Teil 1: Entwicklungsumgebung(en)
Webtechnologien Teil 1: Entwicklungsumgebung(en) 05.04.17 1 Literatur und Links [1-1] Seidler, Kai; Vogelsang, Kay: Das XAMPP Handbuch. Addison-Wesley, 2006 [1-2] http://www.apachefriends.org/download.html
MehrLiteratur und Links. Webtechnologien WS 2017/18 Teil 1/Entwicklung
Literatur und Links [1-1] Seidler, Kai; Vogelsang, Kay: Das XAMPP Handbuch. Addison-Wesley, 2006 [1-2] http://www.apachefriends.org/download.html http://sourceforge.net/projects/xampp/files/ [1-3] http://aktuell.de.selfhtml.org/extras/download.shtml
MehrMobilkommunikation. REST-basierte Dienste für verteilte, mobile Anwendungen. A. Gillert, A. Grebe, M. Hüffmeyer, C. Vogt
Mobilkommunikation REST-basierte Dienste für verteilte, mobile Anwendungen A. Gillert, A. Grebe, M. Hüffmeyer, C. Vogt Fachhochschule Köln, Institut für Nachrichtentechnik Fachhochschule Köln Anton Gillert,
MehrLiteratur. [2-5] Upgrading to TLS Within HTTP/1.1 http://tools.ietf.org/html/rfc2817. Webtechnologien SS 2015 - Teil 2/HTTP
Literatur [2-1] Gourley, David; Totty, Brian: HTTP. The definitive Guide. O'Reilly, 2002 [2-2] Badach, Anatol; Rieger, Sebastian; Schmauch, Matthias: Web- Technologien. Hanser, 2003 [2-3] Hypertext Transfer
MehrBIW Wahlpflichtmodul. Einführung in Solr, Pipeline und REST. Philipp Schaer, TH Köln (University of Applied Sciences), Cologne, Germany
BIW Wahlpflichtmodul Einführung in Solr, Pipeline und REST Philipp Schaer, TH Köln (University of Applied Sciences), Cologne, Germany Version: 2018-05-29 Überblick über gängige Lösungen 2 3 in a nutshell
MehrForms auf Tablets. Vision oder Realität?
Forms auf Tablets Vision oder Realität? Die handelnden Personen Jan-Peter Timmermann Entwickler seit 1985 (Informix) OCP Oracle Forms/Reports, PL/SQL Seit 2000 bei Unternehmen wie Opitz, Trivadis und PITSS
MehrUnified-E Standard WebHttp Adapter
Unified-E Standard WebHttp Adapter Version: 1.5.0.2 und höher Juli 2017 Inhalt 1 Allgemeines... 2 2 Adapter-Parameter in Unified-E... 2 3 Symbolische Adressierung... 3 3.1 ReadValues-Methode... 4 3.2 WriteValues
MehrV by WBR1/BFH-TI 2011 by MOU2/BFH-TI
Java-Applets Unterlagen zum Modul OOP mit Java V 3.0 2007 by WBR1/BFH-TI 2011 by MOU2/BFH-TI Java-Applets V3.0 2011 by WBR1&MOU2/BFH- TI Lernziele Die Kursteilnehmer sind in der Lage: Möglichkeiten und
MehrGrundlagen Internet-Technologien INF3171
Grundlagen Internet-Technologien INF3171 ekaay AJAX Version 1.0 01.07.2013 aktuelles 2 Ajax: zunächst Abkürzung für Asynchronous JavaScript And XML Jesse J. Garrett (AdaptivePath) http://www.adaptivepath.com/publications/essays/archives/
MehrSOAP und REST Ein Vergleich von service- und ressourcenorientierten Architekturen und deren Einsatz im VMA-Projekt
Verteilte und mobile Applikationen - Arbeitsgebiet 3: Verteilte mobile Dienste in Next Generation Networks SOAP und REST Ein Vergleich von service- und ressourcenorientierten Architekturen und deren Einsatz
MehrWeb Services Integration heterogener Systemlandschaften. Prof. Dr. Gregor Engels Fabian Christ 08. Juni 2010
Web s Integration heterogener Systemlandschaften Prof. Dr. Gregor Engels Fabian Christ 08. Juni 2010 Technische Kooperation Datenaustausch / Benutzung technischer Dienste über das Internet Mein Unternehmen
MehrWeb-API Design mit Java
@_openknowledge Web-API Design mit Java API-First Design mit ÜBER OPEN KNOWLEDGE BRANCHENNEUTRALE SOFTWAREENTWICKLUNG UND IT-BERATUNG ÜBER UNS SM STEPHAN MÜLLER Wer bin ich - und wenn ja, wie viele? Enterprise
MehrImplementierung von Web Services: Teil I: Einleitung / SOAP
Implementierung von Web Services: Teil I: Einleitung / SOAP Prof. Dr. Kanne - FSS 2007 Carl-Christian Kanne, February 25, 2007 Web Services - p. 1/12 Web Services: Allgemein XML Datenaustauschformat plattformunabhängig
MehrAktuelle Technologien zur Entwicklung verteilter Anwendungen RESTful Web Services mit JAX-RS
Aktuelle Technologien zur Entwicklung verteilter Anwendungen Überblick, Grundlagen und Entwicklung mit Java Gliederung A. I. Web Services II. RESTful Web Services III. Java API for RESTful Web Services
MehrWiederholung: Beginn
B) Webserivces W3C Web Services Architecture Group: "Ein Web Service ist eine durch einen URI eindeutige identifizierte Softwareanwendung, deren Schnittstellen als XML Artefakte definiert, beschrieben
MehrNode.js Einführung Manuel Hart
Node.js Einführung Manuel Hart Seite 1 Inhalt 1. Node.js - Grundlagen 2. Serverseitiges JavaScript 3. Express.js 4. Websockets 5. Kleines Projekt Seite 2 1. Node.js Grundlagen Node.js is a JavaScript runtime
MehrWebservices. Entwicklercamp Denny Sternberg
Webservices Entwicklercamp 2015 Denny Sternberg Bei Fragen, einfach fragen! Denny Sternberg Seit 2001 entwickeln und admininstrieren von Lotus Domino IBM Certified Application Developer, System Administrator
MehrEinführung: Verteilte Systeme - Remote Method Invocation -
Einführung: Verteilte Systeme - - Prof. Dr. Michael Cebulla 11. Dezember 2014 Fachhochschule Schmalkalden Wintersemester 2014/15 1 / 43 M. Cebulla Verteilte Systeme Gliederung 1 2 Architektur RMI Kommunikation
MehrREST: Eine leichtgewichtige und einfachere Alternative zu Web Services. W3L AG info@w3l.de
1 REST: Eine leichtgewichtige und einfachere Alternative zu Web Services W3L AG info@w3l.de 2009 2 Inhalt Einführung Grundprinzipien der REST-Architektur Beispiel Entwurf von REST-Anwendungen REST mit
MehrAutomatisierung und Integration von Request Tracker Systemen mittels REST-Schnittstelle. Stefan Hornburg. Perlworkshop 2008
Automatisierung und Integration von Request Tracker Systemen mittels REST-Schnittstelle Stefan Hornburg Perlworkshop 2008 split() Request Tracker REST-Schnittstelle Automatisierung Integration Kunden Deutschland:
MehrBenutzerhandbuch. Neukirchen
Benutzerhandbuch Neukirchen August 2015 Kontakt: Kai Hübl Lambertsberg 17 D-34626 Neukirchen kai.huebl@asneg.de 3 Contents 1 Einleitung... 5 1.1 Inhalt... 5 1.2 OpcUaWebServer... 5 1.3 Web Panel... 6 2
MehrWebservices. 1 Einführung 2 Verwendete Standards 3 Web Services mit Java 4 Zusammenfassung. Hauptseminar Internet Dienste
Hauptseminar Internet Dienste Sommersemester 2004 Boto Bako Webservices 1 Einführung 2 Verwendete Standards 3 Web Services mit Java 4 Zusammenfassung Was sind Web Services? Web Services sind angebotene
MehrSODA Die Datenbank als Document Store Rainer Willems Oracle Deutschland B.V. & Co. KG Dreieich Schlüsselworte
SODA Die Datenbank als Document Store Rainer Willems Oracle Deutschland B.V. & Co. KG Dreieich Schlüsselworte SODA, Simple Oracle Document Access, Document Store, Schemaless, JSON, Collections Einleitung
MehrErläuterungen zu Darstellung des DLQ-Datenportals
Erläuterungen zu Darstellung des DLQ-Datenportals Definition zum Datenportal Das DLQ-Datenportal (DP) definiert fachliche Schnittstellen für den Datenaustausch zwischen verschiedenen Kommunikationspartnern.
MehrAPEX Datenverwaltung Wo sind die Daten gerade? Dr. Gudrun Pabst
APEX Datenverwaltung Wo sind die Daten gerade? Dr. Gudrun Pabst Basel Bern Lausanne Zürich Düsseldorf Frankfurt/M. Freiburg i. Br. Hamburg München Stuttgart Wien Voraussetzungen Alles hier gezeigte benötigt
MehrDIAMETER Base Protocol (RFC3588)
Base Protocol (RFC3588) ist eine (nicht rückwärtskompatible) Fortentwicklung des RADIUS Protokolls (Remote Authentication Dial In User Service, RFC2865). Die wichtigsten Unterschiede sind: Es benutzt einen
MehrARCHITEKTUR VON INFORMATIONSSYSTEMEN
ARCHITEKTUR VON INFORMATIONSSYSTEMEN File Transfer Protocol Einleitung Das World Wide Web war ja ursprünglich als verteiltes Dokumentenverwaltungssystem für die akademische Welt gedacht. Das Protokoll
Mehr15. Das Hypertext Transfer Protokoll HTTP - Überblick. 1. Requests und Responses. 2. Content Negotiation. 3. State Management (Cookies)
15. Das Hypertext Transfer Protokoll 15-1 HTTP - Überblick 1. Requests und Responses 2. Content Negotiation 3. State Management (Cookies) 15. Das Hypertext Transfer Protokoll 15-2 HTTP Kommunikation (1)Request
MehrWebbasierte Informationssysteme
SS 2004 Prof. Dr. Stefan Böttcher Universität Paderborn - SS 2004 - Prof. Dr. Stefan Böttcher Folie 1 Was ist eine relationale Datenbank? Menge von Relationen (=Tabellen) und Constraints (=Integritätsbedingungen)
MehrWeb-Anwendungen, SS17 - Fragentypen
Web-Anwendungen, SS17 - Fragentypen Hinweis: Dieses Dokument ist keine Klausur, sondern eine lose (und nicht notwendigerweise vollständige) Sammlung an Fragen wie sie auch in einer Klausur vorkommen könnten.
MehrIntegration von UIS-Webdiensten
Integration von UIS-Webdiensten neue Möglichkeiten durch Web 2.0 basierte Technologien Clemens Düpmeier, Werner Geiger, Claudia Greceanu (duepmeier, geiger, greceanu@iai.fzk.de) Institut für Angewandte
MehrASP.NET Web-API - Grundlagen
ASP.NET Web-API - Grundlagen Kompakt-Intensiv-Training In unserer Schulung "ASP.NET Web API - Grundlagen" werden Ihnen die Grundkenntnisse des REST-Modells vermittelt. So können Sie nach Abschluss der
MehrAPEX Datenverwaltung Wo sind die Daten gerade?
APEX Datenverwaltung Wo sind die Daten gerade? Dr. Gudrun Pabst Trivadis GmbH München Schlüsselworte: APEX, Sessionverwaltung, Dynamic Actions Einleitung Eine APEX-Anwendung wird erst durch zusätzliche
MehrX12L 21. Oktober a) HTML - ein Dateiformat, welches maschinenlesbare Verweise (links) enthält,
1.2 HTML/HTTP 1.2.1 Kurzüberblick: http im Netzwerk Zur Verwirklichung der Hypertextidee brauchte man a) HTML - ein Dateiformat, welches maschinenlesbare Verweise (links) enthält, b) einen (netzwerkfähigen)
MehrHERSTELLERUNABHÄNGIGE FIREWALL AUTOMATISIERUNG
HERSTELLERUNABHÄNGIGE FIREWALL AUTOMATISIERUNG KONSTANTIN AGOUROS, DFN BETRIEBSTAGUNG BERLIN 1 by Xantaro Agenda Warum Automatisierung Wie Automatisierung Programmierbarkeit von Firewalls Juniper Fortinet
MehrClient/Server-Programmierung
Client/Server-Programmierung WS 2017/2018 Betriebssysteme / verteilte Systeme rolanda.dwismuellera@duni-siegena.de Tel.: 0271/740-4050, Büro: H-B 8404 Stand: 12. Januar 2018 Betriebssysteme / verteilte
MehrAnleitung REST API Schneelast-Messsystem SMS
Anleitung REST API Schneelast-Messsystem SMS Version 3.00 REST API Schneelast-Messsystem SMS Die API (Schnittstelle) ist als sogenannter RESTful Webservice angelegt, bei dem jede Funktion über eine eindeutige
MehrNetzwerkprogrammierung unter Linux und UNIX
Netzwerkprogrammierung unter Linux und UNIX Bearbeitet von Stefan Fischer, Walter Müller 2. Auflage 1999. Buch. XII, 228 S. Hardcover ISBN 978 3 446 21093 6 Format (B x L): 14 x 20,9 cm Gewicht: 329 g
MehrMail Integration Solution White Paper
Integration Solution White Paper Inhalt Allgemeine Information... 3 IMAP... 3 Rapid Automation (RA)... 3 RA Agent... 3 RA Solution... 3 Integration Solution... 4 Anwendungsfälle... 5 Download eingehender
MehrWeb-basierte Anwendungssysteme PHP Teil 2
Web-basierte Anwendungssysteme PHP Teil 2 Prof. Dr. Armin Lehmann (lehmann@e-technik.org) Fachbereich 2 Informatik und Ingenieurwissenschaften Wissen durch Praxis stärkt Seite 1 Prof. Dr. Armin Lehmann
MehrSitepark Information Enterprise Server - die Technologie-Plattform von Sitepark
Sitepark Information Enterprise Server - die Technologie-Plattform von Sitepark Der IES ermöglicht die Entwicklung von Produkten auf einer einheitlichen Basis und stellt unter anderem ein produktübergreifendes
MehrPython VS Perl. Storage Monitoring per API statt SNMP. Björn Müller Marcel Denia. comnet GmbH
Python VS Perl Storage Monitoring per API statt SNMP comnet GmbH Björn Müller Marcel Denia comnet GmbH 13.09.2017 Agenda Über uns Ausgangssituation Umsetzung Python Umsetzung Perl??? 13.09.2017 comnet
MehrDatenbereitstellung durch das ARE
Kanton Zürich Amt für Raumentwicklung Geoinformation Datenbereitstellung durch das ARE AV-Tagung 2017, 22. September 2017, Männedorf Michael Boller, Leiter GIS-Koordination Priska Haller, Co-Leiterin GIS-Produkte
MehrDas Hypertext Transfer Protokoll HTTP/1.1
Das Hypertext Transfer Protokoll HTTP/1.1 Michael Dienert 18. Januar 2009 Inhaltsverzeichnis 1 RFC 2616 und RFC 2396 und die Syntaxbeschreibungssprache BNF 1 1.1 Request For Comments.........................
MehrEntwicklung einer Webapplikation zur Vereinfachung der Umsetzung webbasierter Anwendungen
Entwicklung einer Webapplikation zur Vereinfachung der Umsetzung webbasierter Anwendungen Python-BarCamp 2016 02. 03. April 2016 Florian Macherey PGI / JCNS-TA Inhalt Einleitung Grundlagen Konzeption Implementierung
MehrWeb Services. Standards und Realisierung in Java
Standards und Realisierung in Java http://werner.gaulke.net 4.6.2007 Idee Aufbau und Standards und Java Outline 1 Idee Idee hinter? 2 Aufbau und Standards Schichtenmodell WSDL Fazit WSDL SOAP Fazit SOAP
MehrGrundlagen Internet-Technologien. Ajax und Cookies&Sessions Version 1.00
Ajax und Cookies&Sessions Version 1.00 28.6.2010 1 aktuelles 2 Erweiterungen wir betrachten zwei Erweiterungen: Personalisierung der Web-Verbindung durch Cookies & Sessions AJAX: Kombination von Client-
MehrKomponentenorientierte Software-Entwicklung. Seite 1 / 42
Seite 1 / 42 Wiederholung Messaging Java Messaging Service (JMS) Pub/Sub P2P Messaging Middleware XMPP-Protokoll Java API for XML-Processing (JAXP) Java API for XML-Binding Webservices / SOA Simple Object
MehrSicherheit von Webapplikationen Sichere Web-Anwendungen
Sicherheit von Webapplikationen Sichere Web-Anwendungen Daniel Szameitat Agenda 2 Web Technologien l HTTP(Hypertext Transfer Protocol): zustandsloses Protokoll über TCP auf Port 80 HTTPS Verschlüsselt
MehrMULTIPLEXING UND SERVER PUSH
1 MULTIPLEXING UND SERVER PUSH HTTP/2 in Java 9 PROFESSIONALS 2 INDIVIDUALS N3RDS Die Holisticon AG ist eine Management- und IT- Beratung aus Hamburg. Wir entwickeln beste Individualsoftware, Webplattformen
MehrSchnittstellenarchitektur in Zeiten sich wandelnder Frontend-Technologien
Schnittstellenarchitektur in Zeiten sich wandelnder Frontend-Technologien Version: 1.0 Orientation in Objects GmbH Weinheimer Str. 68 68309 Mannheim www.oio.de info@oio.de Ihr Sprecher Thorsten Maier Trainer,
MehrWenn. Schnittstellen. alt werden... Claus Straube IT Architekt
Wenn Schnittstellen alt werden... Claus Straube IT Architekt claus.straube@muenchen.de A B Provider Consumer Request A Response B Provider Consumer Payload Request A Response B Provider Consumer Payload
Mehr