Webtechnologien Wintersemester 2024

Webservices

Aufbau

  • Anwendung, die Maschine-zu-Maschine-Interaktion über ein Netzwerk breitstellt
  • besitzt eine URI (Uniform Resource Identifier)
  • und eine Schnittstellenbeschreibung (beispielsweise in WSDL)
  • kommuniziert mittels Nachrichten (beispielsweise in XML)

Es war einmal …

Websevices

Quelle: WMC

  • Ein Webservice oder Webdienst ist eine Softwareanwendung, die über ein Netzwerk für die direkte Maschine-zu-Maschine-Interaktion bereitgestellt wird.
  • Jeder Webservice besitzt einen Uniform Resource Identifier (URI), über den er eindeutig identifizierbar ist, sowie eine Schnittstellenbeschreibung in maschinenlesbarem Format (als XML-Artefakt, meist WSDL), die definiert, wie mit dem Webservice zu interagieren ist. Die Details der Implementierung des Webservice bleiben so verborgen.
  • Die Kommunikation kann (muss aber nicht) über Protokolle aus dem Internetkontext wie HTTP laufen und XML-basiert sein.
  • Client-Programme senden im Allgemeinen Anfragen an einen Webservice, und dieser antwortet mit der gewünschten Information. Webservices sind Bestandteil von Softwaresystemen, die automatisiert Daten austauschen oder Funktionen auf fernen Rechnern aufrufen.

  • Webservices orientieren sich an der serviceorientierten Architektur (SOA) und vereinen daher verteilte und objektorientierte Programmierstandards und richten sich auf betriebswirtschaftliche Lösungen im Internet.

  • Universal Description, Discovery and Integration (UDDI) Ein standardisierter Verzeichnisdienst (Gelbe Seiten), in dem Webservices und ihre Schnittstellen registriert sind. UDDI umfasst programmierbare Schnittstellen zum dynamischen Auffinden von Webservices. Ende 2005 kündigten die größten Unterstützer von UDDI – IBM, Microsoft und SAP – an, ihren UDDI Verzeichnisdienst UBR (UDDI Business Registry) abzuschalten, was vielerorts als das Ende von UDDI gedeutet wurde.
  • Web Service Description Language (WSDL) Bietet eine XML-Beschreibung der Fähigkeiten eines Webservices.
  • Simple Object Access Protocol (SOAP) Netzwerkprotokoll, mit dessen Hilfe Daten zwischen Systemen ausgetauscht und Remote Procedure Calls durchgeführt werden können. Nutzt meist XML zur Repräsentation der Daten und meist HTTP zum Transport.

WSDL-Beispiel

<definitions name="StockQuote"
   targetNamespace="http://example.com/stockquote.wsdl"
   xmlns:tns="http://example.com/stockquote.wsdl"
   xmlns:xsd1="http://example.com/stockquote.xsd"
   xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
   xmlns="http://schemas.xmlsoap.org/wsdl/">
   <types>
      <schema targetNamespace="http://example.com/stockquote.xsd"
         xmlns="http://www.w3.org/2001/XMLSchema">
         <element name="TradePriceRequest">
            <complexType>
               <all>
                  <element name="tickerSymbol" type="string"/>
               </all>
            </complexType>
         </element>
         <element name="TradePrice">
            <complexType>
               <all>
                  <element name="price" type="float"/>
               </all>
            </complexType>
         </element>
      </schema>
   </types>
   <message name="GetLastTradePriceInput">
      <part name="body" element="xsd1:TradePriceRequest"/>
   </message>
   <message name="GetLastTradePriceOutput">
      <part name="body" element="xsd1:TradePrice"/>
   </message>
   <portType name="StockQuotePortType">
      <operation name="GetLastTradePrice">
         <input message="tns:GetLastTradePriceInput"/>
         <output message="tns:GetLastTradePriceOutput"/>
      </operation>
   </portType>
   <binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType">
      <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
      <operation name="GetLastTradePrice">
         <soap:operation soapAction="http://example.com/GetLastTradePrice"/>
         <input>
            <soap:body use="literal"/>
         </input>
         <output>
            <soap:body use="literal"/>
         </output>
      </operation>
   </binding>
   <service name="StockQuoteService">
      <documentation>My first service</documentation>
      <port name="StockQuotePort" binding="tns:StockQuoteSoapBinding">
         <soap:address location="http://example.com/stockquote"/>
      </port>
   </service>
</definitions>

Quelle: de.wikipedia.org/wiki/WSDL

SOAP-Beispiel

<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
   <env:Header>
      <m:reservation xmlns:m="http://travelcompany.example.org/reservation"
         env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
         env:mustUnderstand="true">
         <m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference>
         <m:dateAndTime>2001-11-29T13:20:00.000-05:00</m:dateAndTime>
      </m:reservation>
      <n:passenger xmlns:n="http://mycompany.example.com/employees"
         env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
         env:mustUnderstand="true">
         <n:name>&Aring;ke J&oacute;gvan &Oslash;yvind</n:name>
      </n:passenger>
   </env:Header>
   <env:Body>
      <p:itinerary
         xmlns:p="http://travelcompany.example.org/reservation/travel">
         <p:departure>
            <p:departing>New York</p:departing>
            <p:arriving>Los Angeles</p:arriving>
            <p:departureDate>2001-12-14</p:departureDate>
            <p:departureTime>late afternoon</p:departureTime>
            <p:seatPreference>aisle</p:seatPreference>
         </p:departure>
         <p:return>
            <p:departing>Los Angeles</p:departing>
            <p:arriving>New York</p:arriving>
            <p:departureDate>2001-12-20</p:departureDate>
            <p:departureTime>mid-morning</p:departureTime>
            <p:seatPreference/>
         </p:return>
      </p:itinerary>
      <q:lodging
         xmlns:q="http://travelcompany.example.org/reservation/hotels">
         <q:preference>none</q:preference>
      </q:lodging>
   </env:Body>
</env:Envelope>

Quelle: IBM / Software information center

  • Weiterentwicklung von XML-RPC.
  • SOAP stützt sich auf XML zur Repräsentation der Daten und auf Internet-Protokolle der Transport- und Anwendungsschicht (vgl. TCP/IP-Referenzmodell) zur Übertragung der Nachrichten. Die gängigste Kombination ist SOAP über HTTP und TCP. SOAP kann beispielsweise auch über SMTP oder JMS verwendet werden. Die Daten müssen nicht zwingend über XML gesendet werden, andere Formate wie CSV sind auch möglich. Die Abkürzung SOAP wird offiziell seit Version 1.2 nicht mehr als Akronym gebraucht, da es erstens (subjektiv) keineswegs einfach (Simple) ist und zweitens nicht nur dem Zugriff auf Objekte (Object Access) dient.
  • Beispiel: SPON
  • XML ist langatmig, anstrengend zu parsen, schwer zu lesen und sein Datenmodell passt nicht zu dem der meisten Programmiersprachen, was wichtig ist, wenn es um Serialisierung geht
  • YouTube, Twitter und andere sind von SOAP/XML zu REST/JSON gewechselt

Moderner Aufbau

  • REST als Architektur
  • Kommunikation unter Nutzung der HTTP-Methoden
  • JSON als Austauschformat

REST

  • Representational State Transfer
  • Bezeichnet ein Paradigma – ist keine Norm
  • Idee: eine URL stellt genau einen Inhalt dar
  • Arbeit mit Inhalten über HTTP-Methoden

Eigenschaften eines REST-Dienstes

  • Adressierbarkeit: Jeder Dienst hat eine eindeutige URL.
  • Unterschiedliche Repräsentationen: .html, .xml, .json
  • Zustandslosigkeit: Jede Nachricht enthält alle zum Verständnis notwendigen Informationen / ist in sich geschlossen.
  • Operationen: Können auf Ressourcen angewendet werden, beispielsweise GET, POST, PUT und DELETE
  • Verwendung von Hypermedia: Repräsentationen (bspw. HTML oder XML) können Links auf andere Ressourcen enthalten (Verbindungshaftigkeit).

  • Adressierbarkeit Jeder Dienst, den ein REST-konformer Server zur Verfügung stellt, hat eine eindeutige Adresse, den Uniform Resource Locator (URL). Diese „Straße und Hausnummer im Netz stellt sicher, dass das Angebot eines Webservices auf einfache, standardisierte Art und Weise einer Vielzahl von Anwendungen (Clients) zur Verfügung steht. Eine konsistente Adressierbarkeit erleichtert es außerdem, einen Webservice als Teil eines Mashups weiterzuverwenden. Zusätzlich zur URL, der den Service selbst adressiert, verwendet REST auch Uniform Resource Identifier (URI), um einzelne Ressourcen zu bezeichnen.

  • Unterschiedliche Repräsentationen Die unter einer Adresse zugänglichen Dienste können unterschiedliche Darstellungsformen (Repräsentationen) haben. Ein REST-konformer Server kann je nachdem, was die Anwendung anfordert, verschiedene Repräsentationen ausliefern (z. B. HTML, JSON oder XML). Damit kann der Standard-Webbrowser über die gleiche URI-Adresse sowohl den Dienst, als auch die Beschreibung oder Dokumentation abrufen.

  • Zustandslosigkeit Zustandslosigkeit wirkt sich begünstigend auf die Skalierbarkeit eines Webservices aus. Beispielsweise können eingehende Anfragen im Zuge der Lastverteilung unkompliziert auf beliebige Maschinen verteilt werden: Da jeder Request in sich geschlossen ist und Anwendungsinformationen somit ausschließlich auf der Seite des Clients vorgehalten werden, ist auf der Seite des Servers keine Sitzungsverwaltung erforderlich. In der Praxis nutzen jedoch viele HTTP-basierte Anwendungen Cookies und andere Techniken, um Zustandsinformationen zu behalten.

  • Operationen REST-konforme Dienste müssen einige Operationen vorsehen, die auf alle Dienste (Ressourcen genannt) angewendet werden können. HTTP zum Beispiel hat eine klar definierte Menge von Operationen, darunter GET, POST, PUT und DELETE. HTTP schreibt vor, dass GET sicher (englisch safe) sein muss, was bedeutet, dass diese Methode nur Informationen beschafft und keine sonstigen Effekte verursacht. Die Methoden GET, HEAD, PUT und DELETE müssen laut HTTP-Spezifikation idempotent sein, was in diesem Zusammenhang bedeutet, dass das mehrfache Absenden der gleichen Anforderung sich nicht anders auswirkt als ein einzelner Aufruf.

  • Hypermedia Wird als logische Erweiterung des Begriffs Hypertext genutzt, in dem Grafiken, Audio, Video, Text und Hyperlinks verflochten sind und ein nichtlineares Informationsmedium darstellen.

HTTP-Befehle

GET Fordert die angegebene Ressource vom Server an.
POST Fügt eine neue (Sub-)Ressource unterhalb der angegebenen Ressource ein.
PUT Die angegebene Ressource wird angelegt / geändert.
PATCH Ein Teil der angegeben Ressource wird geändert.
DELETE Löscht die angegebene Ressource.
HEAD Fordert Metadaten zu einer Ressource vom Server an.
OPTIONS Prüft, welche Methoden auf einer Ressource zur Verfügung stehen.
  • GET: fordert die angegebene Ressource vom Server an. GET weist keine Nebeneffekte auf. Der Zustand am Server wird nicht verändert, weshalb GET als sicher bezeichnet wird.
  • POST: fügt eine neue (Sub-)Ressource unterhalb der angegebenen Ressource ein. Da die neue Ressource noch keine URI besitzt, adressiert den URI die übergeordnete Ressource. Als Ergebnis wird der neue Ressourcenlink dem Client zurückgegeben. POST kann im weiteren Sinne auch dazu verwendet werden Operationen abzubilden, die von keiner anderen Methode abgedeckt werden. Ist nicht idempotent. Ein erneuter Aufruf erstellt für jeden Aufruf mit derselben URI ein neues Objekt, anstatt dasselbe Objekt zurückzugeben.
  • PUT: die angegebene Ressource wird angelegt. Wenn die Ressource bereits existiert, wird sie geändert. Ist idempotent: Der erste Aufruf dieser Methoden mit einer bestimmten URI führt zu Nebeneffekten. Ein erneuter Aufruf mit derselben URI führt zu keinen weiteren Nebeneffekten.
  • PATCH: ein Teil der angegeben Ressource wird geändert. Hierbei sind Nebeneffekte erlaubt.
  • DELETE: löscht die angegebene Ressource. Wenn der Client versucht, eine Ressource zu löschen, die nicht existiert bzw. bereits gelöscht wurde, erhält der Client – sofern die REST-Schnittstelle korrekt implementiert wurde – keine Fehlermeldung (siehe auch: HTTP-Statuscodes). Abhängig von der Implementierung wird eine Ressource meist – entgegen der HTTP-Spezifikation – nicht physisch gelöscht, sondern nur als gelöscht gekennzeichnet und somit versteckt und deaktiviert. Ist idempotent.
  • HEAD: fordert Metadaten zu einer Ressource vom Server an. Keine Nebeneffekte.

  • OPTIONS: prüft, welche Methoden auf einer Ressource zur Verfügung stehen. Keine Nebeneffekte.

  • PATCH, HEAD und OPTIONS werden nicht für CRUD benötigt
  • PUT, POST und PATCH sollten Datensatz zurückliefen

  • In case of a POST that resulted in a creation, use a HTTP 201 status code and include a Location header that points to the URL of the new resource.

  • Im Gegensatz zu vielen RPC-Architekturen kodiert REST keine Methodeninformation in den URI, da der URI Ort und Namen der Ressource angibt, nicht aber die Funktionalität, die die Ressource anbietet. Es wird versucht, die Funktionalität hauptsächlich über die HTTP-Verben abzubilden.

In der Theorie verlangt das Paradigma, dass alle Informationen, die eine Anwendung braucht, um den Seitenzustand wieder herzustellen, in der Anfrage enthalten sind. Dabei identifiziert der URI die Ressource während im HTTP-Header Informationen wie Zugriffsart (GET, PUT), Rückgabeformat oder Authentifizierung enthalten sein können.

  • Definiert keine eigenen Sicherheitsmechanismen, aber HTTPS und OAuth / OpenID
  • Klappt nicht immer: Star / Unstar, Search
  • Filtering: GET /users?state=unverified
  • Aliases: GET /users/recently_added
  • Versionierung: In URL vs. HTTP-Header

Beispiel: SOAP

getUsers()

getNewUsersSince(date SinceDate)

savePurchaseOrder(string CustomerID, string PurchaseOrderID)

Beispiel: REST

GET /users Liste aller Nutzer
GET /users/12 Ein bestimmter Nutzer
POST /users Erstellt einen neuen Nutzer
PUT /users/12 Aktualisiert Nutzer #12
PATCH /users/12 Aktualisiert Nutzer #12 teilweise
DELETE /users/12 Löscht Nutzer #12

JSON

  • JavaScript Object Notation
  • Datenaustauschformat
  • Maschinen- und menschenlesbar
  • JSON-Dokument sollen valides JavaScript sein
  • If all you want to pass around are atomic values or lists or hashes of atomic values, JSON has many of the advantages of XML: it’s straightforwardly usable over the Internet, supports a wide variety of applications, it’s easy to write programs to process JSON, it has few optional features, it’s human-legible and reasonably clear, its design is formal and concise, JSON documents are easy to create, and it uses Unicode.
  • If you’re writing JavaScript in a web browser, JSON is a natural fit.
  • Whitespace vollkommen OK, wenn GZIP

JSON

Beispiel in XML

<Kreditkarte
   Nummer="1234-5678-9012-3456">
   <Inhaber
      Name="Mustermann"
      maennlich="true"
      Alter="42" Partner="null">
      <Hobbys>
         <Hobby>Golfen</Hobby>
         <Hobby>Lesen</Hobby>
      </Hobbys>
      <Kinder />
   </Inhaber>
</Kreditkarte>

Beispiel in JSON

{
   "Nummer": "1234-5678-9012-3456",
   "Inhaber": {
      "Name": "Mustermann",
      "männlich": true,
      "Hobbys": [ "Golfen", "Lesen" ],
      "Alter": 42,
      "Kinder": [],
      "Partner": null
   }
}

Quelle: wikipedia.org

Andere Formate