Webtechnologien
Wintersemester 2024
Webservices
♯
♫
Webservices
<section id="webservices" class="slide cover"><div><h2>Webservices</h2> </div></section> <section class="slide" id="aufbau"><div><h2>Aufbau</h2> <ul> <li>Anwendung, die Maschine-zu-Maschine-Interaktion über ein Netzwerk breitstellt</li> <li>besitzt eine URI (Uniform Resource Identifier)</li> <li>und eine Schnittstellenbeschreibung (beispielsweise in WSDL)</li> <li>kommuniziert mittels Nachrichten (beispielsweise in XML)</li> </ul> </div></section> <section class="slide" id="es-war-einmal-"><div><h2>Es war einmal …</h2> <p><img src="Webservice.svg" alt="Websevices" class="center" /></p> <p class="note">Quelle: <a href="http://commons.wikimedia.org/wiki/File:Webservice.svg">WMC</a></p> <footer> <ul> <li>Ein Webservice oder Webdienst ist eine Softwareanwendung, die über ein Netzwerk für die direkte Maschine-zu-Maschine-Interaktion bereitgestellt wird.</li> <li>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.</li> <li>Die Kommunikation kann (muss aber nicht) über Protokolle aus dem Internetkontext wie HTTP laufen und XML-basiert sein.</li> <li>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.</li> <li> <p>Webservices orientieren sich an der serviceorientierten Architektur (SOA) und vereinen daher verteilte und objektorientierte Programmierstandards und richten sich auf betriebswirtschaftliche Lösungen im Internet.</p> </li> <li>Universal Description, Discovery and Integration (UDDI) Ein standardisierter Verzeichnisdienst (<q>Gelbe Seiten</q>), 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.</li> <li>Web Service Description Language (WSDL) Bietet eine XML-Beschreibung der Fähigkeiten eines Webservices.</li> <li>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.</li> </ul> </footer> </div></section> <section class="slide" id="wsdl-beispiel"><div><h2>WSDL-Beispiel</h2> <pre class="highlight language-xml" data-lang="xml"><code><span class="nt"><definitions</span> <span class="na">name=</span><span class="s">"StockQuote"</span> <span class="na">targetNamespace=</span><span class="s">"http://example.com/stockquote.wsdl"</span> <span class="na">xmlns:tns=</span><span class="s">"http://example.com/stockquote.wsdl"</span> <span class="na">xmlns:xsd1=</span><span class="s">"http://example.com/stockquote.xsd"</span> <span class="na">xmlns:soap=</span><span class="s">"http://schemas.xmlsoap.org/wsdl/soap/"</span> <span class="na">xmlns=</span><span class="s">"http://schemas.xmlsoap.org/wsdl/"</span><span class="nt">></span> <span class="nt"><types></span> <span class="nt"><schema</span> <span class="na">targetNamespace=</span><span class="s">"http://example.com/stockquote.xsd"</span> <span class="na">xmlns=</span><span class="s">"http://www.w3.org/2001/XMLSchema"</span><span class="nt">></span> <span class="nt"><element</span> <span class="na">name=</span><span class="s">"TradePriceRequest"</span><span class="nt">></span> <span class="nt"><complexType></span> <span class="nt"><all></span> <span class="nt"><element</span> <span class="na">name=</span><span class="s">"tickerSymbol"</span> <span class="na">type=</span><span class="s">"string"</span><span class="nt">/></span> <span class="nt"></all></span> <span class="nt"></complexType></span> <span class="nt"></element></span> <span class="nt"><element</span> <span class="na">name=</span><span class="s">"TradePrice"</span><span class="nt">></span> <span class="nt"><complexType></span> <span class="nt"><all></span> <span class="nt"><element</span> <span class="na">name=</span><span class="s">"price"</span> <span class="na">type=</span><span class="s">"float"</span><span class="nt">/></span> <span class="nt"></all></span> <span class="nt"></complexType></span> <span class="nt"></element></span> <span class="nt"></schema></span> <span class="nt"></types></span> <span class="nt"><message</span> <span class="na">name=</span><span class="s">"GetLastTradePriceInput"</span><span class="nt">></span> <span class="nt"><part</span> <span class="na">name=</span><span class="s">"body"</span> <span class="na">element=</span><span class="s">"xsd1:TradePriceRequest"</span><span class="nt">/></span> <span class="nt"></message></span> <span class="nt"><message</span> <span class="na">name=</span><span class="s">"GetLastTradePriceOutput"</span><span class="nt">></span> <span class="nt"><part</span> <span class="na">name=</span><span class="s">"body"</span> <span class="na">element=</span><span class="s">"xsd1:TradePrice"</span><span class="nt">/></span> <span class="nt"></message></span> <span class="nt"><portType</span> <span class="na">name=</span><span class="s">"StockQuotePortType"</span><span class="nt">></span> <span class="nt"><operation</span> <span class="na">name=</span><span class="s">"GetLastTradePrice"</span><span class="nt">></span> <span class="nt"><input</span> <span class="na">message=</span><span class="s">"tns:GetLastTradePriceInput"</span><span class="nt">/></span> <span class="nt"><output</span> <span class="na">message=</span><span class="s">"tns:GetLastTradePriceOutput"</span><span class="nt">/></span> <span class="nt"></operation></span> <span class="nt"></portType></span> <span class="nt"><binding</span> <span class="na">name=</span><span class="s">"StockQuoteSoapBinding"</span> <span class="na">type=</span><span class="s">"tns:StockQuotePortType"</span><span class="nt">></span> <span class="nt"><soap:binding</span> <span class="na">style=</span><span class="s">"document"</span> <span class="na">transport=</span><span class="s">"http://schemas.xmlsoap.org/soap/http"</span><span class="nt">/></span> <span class="nt"><operation</span> <span class="na">name=</span><span class="s">"GetLastTradePrice"</span><span class="nt">></span> <span class="nt"><soap:operation</span> <span class="na">soapAction=</span><span class="s">"http://example.com/GetLastTradePrice"</span><span class="nt">/></span> <span class="nt"><input></span> <span class="nt"><soap:body</span> <span class="na">use=</span><span class="s">"literal"</span><span class="nt">/></span> <span class="nt"></input></span> <span class="nt"><output></span> <span class="nt"><soap:body</span> <span class="na">use=</span><span class="s">"literal"</span><span class="nt">/></span> <span class="nt"></output></span> <span class="nt"></operation></span> <span class="nt"></binding></span> <span class="nt"><service</span> <span class="na">name=</span><span class="s">"StockQuoteService"</span><span class="nt">></span> <span class="nt"><documentation></span>My first service<span class="nt"></documentation></span> <span class="nt"><port</span> <span class="na">name=</span><span class="s">"StockQuotePort"</span> <span class="na">binding=</span><span class="s">"tns:StockQuoteSoapBinding"</span><span class="nt">></span> <span class="nt"><soap:address</span> <span class="na">location=</span><span class="s">"http://example.com/stockquote"</span><span class="nt">/></span> <span class="nt"></port></span> <span class="nt"></service></span> <span class="nt"></definitions></span> </code></pre> <p class="note right">Quelle: <a href="https://de.wikipedia.org/wiki/WSDL">de.wikipedia.org/wiki/WSDL</a></p> </div></section> <section class="slide" id="soap-beispiel"><div><h2>SOAP-Beispiel</h2> <pre class="highlight language-xml" data-lang="xml"><code><span class="cp"><?xml version='1.0' ?></span> <span class="nt"><env:Envelope</span> <span class="na">xmlns:env=</span><span class="s">"http://www.w3.org/2003/05/soap-envelope"</span><span class="nt">></span> <span class="nt"><env:Header></span> <span class="nt"><m:reservation</span> <span class="na">xmlns:m=</span><span class="s">"http://travelcompany.example.org/reservation"</span> <span class="na">env:role=</span><span class="s">"http://www.w3.org/2003/05/soap-envelope/role/next"</span> <span class="na">env:mustUnderstand=</span><span class="s">"true"</span><span class="nt">></span> <span class="nt"><m:reference></span>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d<span class="nt"></m:reference></span> <span class="nt"><m:dateAndTime></span>2001-11-29T13:20:00.000-05:00<span class="nt"></m:dateAndTime></span> <span class="nt"></m:reservation></span> <span class="nt"><n:passenger</span> <span class="na">xmlns:n=</span><span class="s">"http://mycompany.example.com/employees"</span> <span class="na">env:role=</span><span class="s">"http://www.w3.org/2003/05/soap-envelope/role/next"</span> <span class="na">env:mustUnderstand=</span><span class="s">"true"</span><span class="nt">></span> <span class="nt"><n:name></span><span class="ni">&Aring;</span>ke J<span class="ni">&oacute;</span>gvan <span class="ni">&Oslash;</span>yvind<span class="nt"></n:name></span> <span class="nt"></n:passenger></span> <span class="nt"></env:Header></span> <span class="nt"><env:Body></span> <span class="nt"><p:itinerary</span> <span class="na">xmlns:p=</span><span class="s">"http://travelcompany.example.org/reservation/travel"</span><span class="nt">></span> <span class="nt"><p:departure></span> <span class="nt"><p:departing></span>New York<span class="nt"></p:departing></span> <span class="nt"><p:arriving></span>Los Angeles<span class="nt"></p:arriving></span> <span class="nt"><p:departureDate></span>2001-12-14<span class="nt"></p:departureDate></span> <span class="nt"><p:departureTime></span>late afternoon<span class="nt"></p:departureTime></span> <span class="nt"><p:seatPreference></span>aisle<span class="nt"></p:seatPreference></span> <span class="nt"></p:departure></span> <span class="nt"><p:return></span> <span class="nt"><p:departing></span>Los Angeles<span class="nt"></p:departing></span> <span class="nt"><p:arriving></span>New York<span class="nt"></p:arriving></span> <span class="nt"><p:departureDate></span>2001-12-20<span class="nt"></p:departureDate></span> <span class="nt"><p:departureTime></span>mid-morning<span class="nt"></p:departureTime></span> <span class="nt"><p:seatPreference/></span> <span class="nt"></p:return></span> <span class="nt"></p:itinerary></span> <span class="nt"><q:lodging</span> <span class="na">xmlns:q=</span><span class="s">"http://travelcompany.example.org/reservation/hotels"</span><span class="nt">></span> <span class="nt"><q:preference></span>none<span class="nt"></q:preference></span> <span class="nt"></q:lodging></span> <span class="nt"></env:Body></span> <span class="nt"></env:Envelope></span> </code></pre> <p class="note right">Quelle: <a href="http://publib.boulder.ibm.com/infocenter/cicsts/v3r1/index.jsp?topic=%2Fcom.ibm.cics.ts31.doc%2Fdfhws%2Fconcepts%2Fsoap%2Fdfhws_message.htm">IBM / Software information center</a></p> <footer> <ul> <li>Weiterentwicklung von XML-RPC.</li> <li>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.</li> <li>Beispiel: SPON</li> <li>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</li> <li>YouTube, Twitter und andere sind von SOAP/XML zu REST/JSON gewechselt</li> </ul> </footer> </div></section> <section class="slide" id="moderner-aufbau"><div><h2>Moderner Aufbau</h2> <ul> <li>REST als Architektur</li> <li>Kommunikation unter Nutzung der HTTP-Methoden</li> <li>JSON als Austauschformat</li> </ul> </div></section> <section class="slide" id="rest"><div><h2>REST</h2> <ul> <li><strong>Re</strong>presentational <strong>S</strong>tate <strong>T</strong>ransfer</li> <li>Bezeichnet ein Paradigma – ist keine Norm</li> <li>Idee: eine URL stellt genau einen Inhalt dar</li> <li>Arbeit mit Inhalten über HTTP-Methoden</li> </ul> </div></section> <section class="slide" id="eigenschaften-eines-rest-dienstes"><div><h2>Eigenschaften eines REST-Dienstes</h2> <ul> <li><strong>Adressierbarkeit</strong>: Jeder Dienst hat eine eindeutige URL.</li> <li><strong>Unterschiedliche Repräsentationen</strong>: <code class="language-plaintext highlighter-rouge">.html</code>, <code class="language-plaintext highlighter-rouge">.xml</code>, <code class="language-plaintext highlighter-rouge">.json</code></li> <li><strong>Zustandslosigkeit</strong>: Jede Nachricht enthält alle zum Verständnis notwendigen Informationen / ist in sich geschlossen.</li> <li><strong>Operationen</strong>: Können auf Ressourcen angewendet werden, beispielsweise <code class="language-plaintext highlighter-rouge">GET</code>, <code class="language-plaintext highlighter-rouge">POST</code>, <code class="language-plaintext highlighter-rouge">PUT</code> und <code class="language-plaintext highlighter-rouge">DELETE</code></li> <li><strong>Verwendung von Hypermedia</strong>: Repräsentationen (bspw. HTML oder XML) können Links auf andere Ressourcen enthalten (Verbindungshaftigkeit).</li> </ul> <footer> <ul> <li> <p><strong>Adressierbarkeit</strong> 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<q> 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.</p> </li> <li> <p><strong>Unterschiedliche Repräsentationen</strong> 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.</p> </li> <li> <p><strong>Zustandslosigkeit</strong> 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.</p> </li> <li> <p><strong>Operationen</strong> 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 <q>sicher</q> (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.</p> </li> <li> <p><strong>Hypermedia</strong> Wird als logische Erweiterung des Begriffs Hypertext genutzt, in dem Grafiken, Audio, Video, Text und Hyperlinks verflochten sind und ein nichtlineares Informationsmedium darstellen.</p> </li> </ul> </footer> </div></section> <section class="slide" id="http-befehle"><div><h2>HTTP-Befehle</h2> <table> <tbody> <tr> <td><code class="language-plaintext highlighter-rouge">GET</code></td> <td>Fordert die angegebene Ressource vom Server an.</td> </tr> <tr> <td><code class="language-plaintext highlighter-rouge">POST</code></td> <td>Fügt eine neue (Sub-)Ressource unterhalb der angegebenen Ressource ein.</td> </tr> <tr> <td><code class="language-plaintext highlighter-rouge">PUT</code></td> <td>Die angegebene Ressource wird angelegt / geändert.</td> </tr> <tr> <td><code class="language-plaintext highlighter-rouge">PATCH</code></td> <td>Ein Teil der angegeben Ressource wird geändert.</td> </tr> <tr> <td><code class="language-plaintext highlighter-rouge">DELETE</code></td> <td>Löscht die angegebene Ressource.</td> </tr> <tr> <td><code class="language-plaintext highlighter-rouge">HEAD</code></td> <td>Fordert Metadaten zu einer Ressource vom Server an.</td> </tr> <tr> <td><code class="language-plaintext highlighter-rouge">OPTIONS</code></td> <td>Prüft, welche Methoden auf einer Ressource zur Verfügung stehen.</td> </tr> </tbody> </table> <footer> <ul> <li><strong>GET</strong>: 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.</li> <li><strong>POST</strong>: 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.</li> <li><strong>PUT</strong>: 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.</li> <li><strong>PATCH</strong>: ein Teil der angegeben Ressource wird geändert. Hierbei sind Nebeneffekte erlaubt.</li> <li><strong>DELETE</strong>: 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.</li> <li><strong>HEAD</strong>: fordert Metadaten zu einer Ressource vom Server an. Keine Nebeneffekte.</li> <li> <p><strong>OPTIONS</strong>: prüft, welche Methoden auf einer Ressource zur Verfügung stehen. Keine Nebeneffekte.</p> </li> <li>PATCH, HEAD und OPTIONS werden nicht für CRUD benötigt</li> <li>PUT, POST und PATCH sollten Datensatz zurückliefen</li> <li> <p>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.</p> </li> <li>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.</li> </ul> <p>In der Theorie verlangt das Paradigma, dass <em>alle</em> 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.</p> <ul> <li>Definiert keine eigenen Sicherheitsmechanismen, aber HTTPS und OAuth / OpenID</li> <li>Klappt nicht immer: Star / Unstar, Search</li> <li>Filtering: GET /users?state=unverified</li> <li>Aliases: GET /users/recently_added</li> <li>Versionierung: In URL vs. HTTP-Header</li> </ul> </footer> </div></section> <section class="slide" id="beispiel-soap"><div><h2>Beispiel: SOAP</h2> <pre class="highlight language-java" data-lang="java"><code><span class="n">getUsers</span><span class="o">()</span> <span class="n">getNewUsersSince</span><span class="o">(</span><span class="n">date</span> <span class="nc">SinceDate</span><span class="o">)</span> <span class="n">savePurchaseOrder</span><span class="o">(</span><span class="n">string</span> <span class="nc">CustomerID</span><span class="o">,</span> <span class="n">string</span> <span class="nc">PurchaseOrderID</span><span class="o">)</span> </code></pre> </div></section> <section class="slide" id="beispiel-rest"><div><h2>Beispiel: REST</h2> <table> <tbody> <tr> <td><code class="language-plaintext highlighter-rouge">GET</code></td> <td><code class="language-plaintext highlighter-rouge">/users</code></td> <td>Liste aller Nutzer</td> </tr> <tr> <td><code class="language-plaintext highlighter-rouge">GET</code></td> <td><code class="language-plaintext highlighter-rouge">/users/12</code></td> <td>Ein bestimmter Nutzer</td> </tr> <tr> <td><code class="language-plaintext highlighter-rouge">POST</code></td> <td><code class="language-plaintext highlighter-rouge">/users</code></td> <td>Erstellt einen neuen Nutzer</td> </tr> <tr> <td><code class="language-plaintext highlighter-rouge">PUT</code></td> <td><code class="language-plaintext highlighter-rouge">/users/12</code></td> <td>Aktualisiert Nutzer #12</td> </tr> <tr> <td><code class="language-plaintext highlighter-rouge">PATCH</code></td> <td><code class="language-plaintext highlighter-rouge">/users/12</code></td> <td>Aktualisiert Nutzer #12 teilweise</td> </tr> <tr> <td><code class="language-plaintext highlighter-rouge">DELETE</code></td> <td><code class="language-plaintext highlighter-rouge">/users/12</code></td> <td>Löscht Nutzer #12</td> </tr> </tbody> </table> </div></section> <section class="slide" id="json"><div><h2>JSON</h2> <ul> <li>JavaScript Object Notation</li> <li>Datenaustauschformat</li> <li>Maschinen- und menschenlesbar</li> <li>JSON-Dokument sollen valides JavaScript sein</li> </ul> <footer> <ul> <li>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.</li> <li><q>If you’re writing JavaScript in a web browser, JSON is a natural fit.</q></li> <li>Whitespace vollkommen OK, wenn GZIP</li> </ul> </footer> </div></section> <section class="slide" id="json-1"><div><h2>JSON</h2> <div class="parts "> <div class="part"> <h3 id="beispiel-in-xml">Beispiel in XML</h3> <pre class="highlight language-xml" data-lang="xml"><code><span class="nt"><Kreditkarte</span> <span class="na">Nummer=</span><span class="s">"1234-5678-9012-3456"</span><span class="nt">></span> <span class="nt"><Inhaber</span> <span class="na">Name=</span><span class="s">"Mustermann"</span> <span class="na">maennlich=</span><span class="s">"true"</span> <span class="na">Alter=</span><span class="s">"42"</span> <span class="na">Partner=</span><span class="s">"null"</span><span class="nt">></span> <span class="nt"><Hobbys></span> <span class="nt"><Hobby></span>Golfen<span class="nt"></Hobby></span> <span class="nt"><Hobby></span>Lesen<span class="nt"></Hobby></span> <span class="nt"></Hobbys></span> <span class="nt"><Kinder</span> <span class="nt">/></span> <span class="nt"></Inhaber></span> <span class="nt"></Kreditkarte></span> </code></pre> </div><div class="part"> <h3 id="beispiel-in-json">Beispiel in JSON</h3> <pre class="highlight language-json" data-lang="json"><code><span class="p">{</span><span class="w"> </span><span class="nl">"Nummer"</span><span class="p">:</span><span class="w"> </span><span class="s2">"1234-5678-9012-3456"</span><span class="p">,</span><span class="w"> </span><span class="nl">"Inhaber"</span><span class="p">:</span><span class="w"> </span><span class="p">{</span><span class="w"> </span><span class="nl">"Name"</span><span class="p">:</span><span class="w"> </span><span class="s2">"Mustermann"</span><span class="p">,</span><span class="w"> </span><span class="nl">"männlich"</span><span class="p">:</span><span class="w"> </span><span class="kc">true</span><span class="p">,</span><span class="w"> </span><span class="nl">"Hobbys"</span><span class="p">:</span><span class="w"> </span><span class="p">[</span><span class="w"> </span><span class="s2">"Golfen"</span><span class="p">,</span><span class="w"> </span><span class="s2">"Lesen"</span><span class="w"> </span><span class="p">],</span><span class="w"> </span><span class="nl">"Alter"</span><span class="p">:</span><span class="w"> </span><span class="mi">42</span><span class="p">,</span><span class="w"> </span><span class="nl">"Kinder"</span><span class="p">:</span><span class="w"> </span><span class="p">[],</span><span class="w"> </span><span class="nl">"Partner"</span><span class="p">:</span><span class="w"> </span><span class="kc">null</span><span class="w"> </span><span class="p">}</span><span class="w"> </span><span class="p">}</span><span class="w"> </span></code></pre> </div> </div> <p class="note right">Quelle: <a href="https://de.wikipedia.org/wiki/JSON">wikipedia.org</a></p> </div></section> <section class="slide" id="andere-formate"><div><h2>Andere Formate</h2> <ul> <li>Plain Text.txt</li> <li>Comma-separated values.csv</li> <li>MongoDBs <a href="http://bsonspec.org/">BSON</a> (Binary JSON)</li> <li>Googles <a href="https://google.github.io/flatbuffers/">FlatBuffers</a> (Weiterentwicklung der <a href="https://code.google.com/p/protobuf/">Protocol Buffers</a>) (<q><a href="https://code.facebook.com/posts/872547912839369/improving-facebook-s-performance-on-android-with-flatbuffers/">Improving Facebook’s performance on Android with FlatBuffers</a></q>)</li> </ul> </div></section> <section class="slide" id="links"><div><h2>Links</h2> <ul> <li><a href="http://www.json.org/json-de.html">json.org</a></li> <li><a href="http://restcookbook.com/">restcookbook.com</a></li> <li><a href="http://graph.facebook.com/4?fields=id,name,gender,picture">graph.facebook.com</a></li> <li><a href="http://developer.rottentomatoes.com/docs/json/v10/Top_Rentals">Rotten Tomatoes API</a></li> <li><a href="http://openweathermap.org/">openweathermap.org</a></li> <li><a href="https://codewords.recurse.com/issues/five/what-restful-actually-means">What RESTful actually means</a></li> <li>Liste an öffentlichen APIs: <a href="https://github.com/public-apis/public-apis">github.com/public-apis</a>, <a href="https://github.com/n0shake/Public-APIs">github.com/n0shake/Public-APIs</a></li> </ul> </div></section>