Unsere Datenschutzrichtlinie wird in Kürze aktualisiert. Bitte sehen Sie sich die Vorschau an.

Java EE 7: Web Services

Einführung in RESTful Services und die JAX-RS

LinkedIn Learning kostenlos und unverbindlich testen!

Jetzt testen Alle Abonnements anzeigen
Hier erfahren Sie, was RESTful Services sind, welche HTTP-Methoden üblicherweise verwendet werden und wie JSON aussieht. Das Video zeigt, was die JAX-RS-Spezifikation beinhaltet und einige HTTP-Requests in Aktion.

Transkript

RESTful Services und JSON sind ein Ansatz, mit dem sich verteilte Applikationen im Webumfeld sehr einfach und schnell realisieren lassen. In der Java haben wir mit JAX-RS eine API-Spezifikation, um RESTful Services bereitstellen und auch konsumieren zu können. In diesem Video werden wir besprechen, was RESTful Services sind, was JSON ist und was die JAX-RS-Spezifikation beinhaltet. Widmen wir uns zunächst der Frage, was die JAX-RS überhaupt ist. Die JAX-RS ist eine Spezifikation. Sie ist definiert im JSR 339. Sie kann seit Version 1 RESTful Services bereitstellen. Sie deckt also den serverseitigen Anteil von RESTful Services ab, nämlich das Bereitstellen und Verfügbarmachen von ihnen. Seit Java EE 7, also in der aktuellen Version, ist die JAX-RS auch in der Lage, RESTful Services zu konsumieren. Das bedeutet, wir haben auch eine client-seitige Schnittstelle, genau genommen eigentlich zwei, mit denen wir RESTful Services konsumieren und Anforderungen an RESTful Services senden können. Das Ganze ist dann ein übergreifener Ansatz über die verschiedenen Die bekanntesten davon sind Apache Jersey und Rest Easy von der JBoss Foundation, die sich jetzt alle der JAX-RS-API unterordnen und es uns erlauben, dass wir mit ein- und demselben Code mit verschiedenen Frameworks arbeiten können. JAX-RS dient, egal auf welcher Seite, also Server oder Client, wir das betrachten, dem Bereitstellen beziehungsweise Ansprechen von RESTful Services. RESTful Services wiederum sind anders als zum Beispiel XML Web Services eine Konvention, keine Spezifikation. Das heißt, es steht, auch wieder anders als bei XML Web Services, nicht eine einzelne Organisation dahinter, die verantwortlich dafür ist, dass die RESTful Services in irgendeiner Art umgesetzt oder interpretiert werden, sondern es ist eine Konvention, die übergreifend einfach von verschiedenen Entwicklern, verschiedenen Communities und verschiedenen Firmen getragen wird. Der Gedanke hinter RESTful Services ist, dass im Webumfeld alles eindeutig identifiziert und per HTTP-Request angesprochen werden kann. RESTful Services basieren dabei im Grunde auf dem Modell, was wir auch mit dem Browser fahren, wenn wir die Webseite aufrufen und Inhalte von der Webseite abrufen. Dabei wird ein HTTP-Request an den Server gesandt und der Server wird anhand dieses HTTP-Requests die identifizierte Ressource aufrufen, gegebenenfalls verarbeiten und das Ergebnis zurückliefern. Das Ganze macht man sich im Webumfeld zunutze und sagt: Wir wollen mit RESTful Services denselben Gedanken für den Datenaustausch nutzen. Dabei entscheidet ganz wesentlich die Art des HTTP-Requests, wie mit der Ressource, die wir angesprochen haben, umgegangen wird. Das Ansprechen einer Ressource erfolgt übrigens über die Adresse. Das bedeutet, dass normalerweise innerhalb der aufgerufenen Adresse schon einige zusätzliche Informationen, wie zum Beispiel eine Datensatz-ID oder ähnliches verarbeitet werden können. Wir unterscheiden bei RESTful Services mehrere Arten von HTTP-Requests. Schauen wir uns die wesentlichsten Arten dieser HTTP-Requests an. Der bekannteste HTTP-Request, den Sie auch jeden Tag, wenn Sie mit dem Browser arbeiten, nutzen, ist der GET-Request. Der GET-Request dient im RESTful-Umfeld dazu, eine Ressource abzurufen. Übrigens nicht nur dort. Dasselbe gilt auch für die Verwendung innerhalb eines Browsers. Dabei wird die Ressource eindeutig identifiziert und der Server wird, und das ist jetzt RESTful-spezifisch, hingehen, nachschauen, ob er diese Ressource finden kann, sie eventuell aufrufen und verarbeiten lassen und das Ergebnis dieser Verarbeitung zurückgeben. Existiert diese Ressource nicht, ist es dem Implementierer selbst überlassen, wie er damit umgeht. Eine Ressource anlegen, zum Beispiel einen Datensatz in einer Datenbank, machen wir mit Hilfe eines POST-Requests. Dieser POST-Request beinhaltet dann alle Informationen, die vom Server benötigt werden, um die Ressource anzulegen und dann eben auch entsprechend verarbeiten zu können. Eine bereits angelegte Ressource können wir wieder über einen GET-Request abrufen, wenn uns zum Beispiel die Datensatz-ID bekannt ist. Mit Hilfe eines PUT-Requests wird eine Ressource üblicherweise geupdatet. Sie existiert also schon und wir übertragen die zu ändernden Daten oder alle Daten, so dass der Server in der Lage ist, die Ressource zu identifizieren, zu laden, Änderungen vorzunehmen und sie zu speichern. Diese Funktionalitäten, Laden, Speichern, und so weiter, müssen wir natürlich selber implementieren. Da gibt es keine Automatismen. Die Art des HTTP-Requests ist im Grunde nichts anderes als eine gemeinsame Konvention, über die man spricht und anhand derer man bestimmte Operationen unterscheidbar voneinander macht. Ein weiterer möglicher HTTP-Request, den wir verwenden können, ist der DELETE-Request. Mit dem werden dann eindeutig identifzierte Ressourcen gelöscht. Die Implementierung dieser verschiedenen Requests obliegt letzlich Ihnen als Programmierer. Ganz wesentlich bei RESTful Services ist, dass wir anders als bei zum Beispiel XML Web Services keinen Contract-First-Ansatz haben. Es gibt also vorher keine Vereinbarung zwischen dem Anbieter und dem Nutzer, jedenfalls nicht in Form eines wie auch immer gearteten Vertrags. Bei XML Web Services ist dieser Vertrag eine WSDL-Datei die man abrufen kann, und anhand derer der entsprechende Client automatisch erzeugt wird. Das gibt es bei RESTful Services nicht. Hier müssen die Clients die Spezifikation selber kennen. Das heißt, dass Sie als Implementierer möglicherweise auch von Ihrem Service-Anbieter Dokumentationen bekommen. Das ist meistens das, was Sie unter dem Schlagwort API-Dokumentation kennen. Diese Dokumentation beinhaltet dann meistens Aufrufe und die dabei zu übermittelnden Daten und Sie müssen das Ganze auf Ebene Ihres Clients dann selbst implementieren. Das ist zum Glück relativ einfach, denn RESTful Services sind viel leichtgewichtiger das meint nicht nur den Datenaustausch, sondern auch den Implementierungsaufwand, als es XML Web Services sind. Üblicherweise dient zum Datenaustausch das Format JSON. JSON steht dabei für JavaScript Objekt Notation und ist letztlich die serialisierte Darstellung von JavaScript-Objekten. Die werden dann genutzt, an den Server übertragen. Dort gibt es Bibliotheken, mit denen man JSON ausparsen kann. Es gibt übrigens auch in der Java EE mit JSONP eine API-Spezifikation, die das Ganze dann auch übergreifend verfügbar macht. Der Server verarbeitet die ausgeparsten Informationen und liefert dann in aller Regel auch JSON zum Client zurück. Das kann der Client dann seinerseits auch wieder ausparsen. Durch dieses JSON-Datenaustauschformat ist auch die Plattformunabhängigkeit gegeben, da JSON ein vergleichsweise einfaches Format ist. XML selber ist ja auch schon plattformunabhängig, hat aber eine Menge Markup. Öffnende, schließende Tags und ähnliches müssen also immer transportiert werden. Das ist bei JSON nicht der Fall. JSON ist leichtgewichtiger. Wir übertragen sozusagen Name-Wert-Paare. Aber wir können bei JSON trotzdem tiefe Strukturen übertragen. Wir können ein Objekt zurückgeben, das zum Beispiel untergeordnet eine Liste von anderen Objekten enthält. Was wir damit anfangen, müssen wir auf dem Client selber entscheiden und dort implementieren. Das ist aber auf jeder Plattform eigentlich sehr leicht möglich. JSON kommt aus der JavaScript-Welt und ist damit speziell von JavaScript aus gut nutzbar. Das heißt, die neuen Single-Page- Webapplikationen, die gerade so angesagt sind, setzen ganz extensiv auf RESTful Services und JSON und da ist der Ablauf in der Regel der, dass ein HTTP-Request an den Server geschickt wird, JSON kommt zurück, dieses JSON wird von JavaScript in Objekte umgewandelt und dann wird das JavaScript, was im Browser läuft, die Webseitendarstellung selbständig lokal aktualisieren. Das heißt, wir müssen weniger Daten vom Server holen, weil das ganze HTML vom Browser selber erzeugt wird und nicht mehr, wie sonst üblich, vom Server zurückgegeben wird. Wesentlich weniger Daten und damit auch eine wesentlich schnellere Verarbeitungsgeschwindigkeit. Genau das gleiche macht man sich dann bei mobilen Applikationen zunutze. Hier ist es so, dass die mobilen Applikationen Requests an die RESTful Services-Schnittstelle senden, JSON hinschicken, JSON zurückbekommen und dieses JSON auch wieder auf den verschiedenen Plattformen ausgeparst und weiterverarbeitet wird. Grundsätzlich müssen wir bitte im Hinterkopf behalten, wir befinden uns hier im HTTP- und Webapplikationsumfeld. Das bedeutet, wir arbeiten zustandslos. Das bedeutet auch, dass der Client selber dafür verantwortlich ist, wie er mit den übergebenen und zurückgegebenen Daten umgeht und gegebenfalls dem Server wieder benötigte Informationen bereitstellen muss Das wird aber in aller Regel in der Schnittstellenspezifikation so erwähnt. Nach so viel Vorrede werfen wir nun einmal einen Blick darauf, wie ein Aufruf auf eine RESTful Services- Schnittstelle aussehen kann, was man zurückbekommt, und wir werfen einen kurzen Blick darauf, wie so ein JSON-Dokument aussehen kann, was dann übertragen wird. Wir befinden uns hier im Fiddler-Tool. Fiddler ist ein kostenloser Webproxy, den man auf Windows- Systemen einsetzen kann Mit dessen Composer kann man HTTP-Requests auslösen und sich die Rückgabe anschauen. Wir werden jetzt verschiedene HTTP-Requests auslösen und zwar gehen die alle auf dem aktuellen Server deployten Rest-Service. Der hat im Grunde zwei Methoden, nämlich hello und multiple, aber erst widmen wir uns der hello-Methode Was wir hier sehen und was ich jetzt hervorhebe, ist ein kompletter HTTP-Request. So ein HTTP-Request besteht immer aus zwei Teilen, nämlich dem Header und abgetrennt durch eine Leerzeile dem Body. Der Body transportiert normalerweise die Informationen, die vom RESTful Service zu verarbeiten sind. Im Header geben wir zunächst einmal an, wie wir auf diesen Service zugreifen wollen. Die HTTP-Methode wird hier angegeben, nämlich get. Das heißt, wir machen einen GET-Request zum Server. Die Maschine ist angegeben über host und den Content Type benutzen wir, um dem Server zu signalisieren, was er jetzt für Daten bekommt. Bei HTML-Formularen ist das sicher ein anderer Content Type als hier, wo wir JSON-formatierte Daten übertragen wollen. Ich klicke mal auf Execute. Jetzt wird dieser HTTP-Request ausgeführt. Ich kann mir die Rückgabe anschauen und die Rückgabe, die ich bekommen habe, ist ebenfalls wieder eine HTTP Response, in dem Fall. Sie hat denselben Aufbau wie der Request. Nämlich einen Header und den eigentlichen Inhalt. Der eigentliche Inhalt ist einigermaßen deckungsgleich mit dem von mir versandten. Allerdings ist er auf Serverseite manipuliert worden, um auszudrücken, dass wir eine Verarbeitung vorgenommen haben. Nun gehen wir zurück in den Composer und werden jetzt einmal noch einen zusätzlichen Header-Wert einfügen. Nämlich Accept mit dem Wert text.xml. Wenn ich das in meinen RESTful Services entsprechend implementiert habe, werde ich nun eine Rückgabe bekommen, die den Datentyp XML beinhaltet und nicht wie zuvor JSON. Das Ganze wird über JAX-RS entsprechend abgebildet. Das kann ich, wenn ich meinen RESTful Service schreibe, angeben, dass wir dort zum Beispiel auch XML zurückgeben können. So kann der Client mit Hilfe des Accept-Headers ausdrücken, was er tatsächlich für einen Rückgabe-Content-Typen haben möchte. Bei RESTful Services sind die angesprungenen Adressen durchaus auch selber Informationsträger. Hier in dem Fall sprechen wir die Methode multiple des RESTful Services HelloWorld an. Hier geben wir im Pfad noch eine zusätzliche Information mit. Nämlich die Anzahl der Wiederholungen, die jetzt intern dargestellt werden sollen Es ist selber eigentlich kein echter Pfadbestandteil. Sondern es ist eine Zusatzinformation. Die wird von JAX-RS entgegengenommen und kann dann entsprechend verarbeitet werden. Hier verwende ich als HTTP-Requesttyp post. Das heißt ich signalisiere dem Server, dass er einen Datensatz anlegen soll. Das macht hier überhaupt keinen Unterschied zu dem, was wir bei dem GET-Request gemacht haben, diese Signalisierung. Es ist nur eine andere Art, wie die Daten übertragen werden. Für den Server ist es letztlich die Indikation, die stattfinden soll. Ich kann mich daran im JAX-RS binden und dementsprechend zum Beispiel für ein- und dieselbe Ressource, also multiple oder hello auf Ebene der HTTP-Zugriffstypen nochmal unterschiedliche Verarbeitungslogiken implementieren. Das ist aber nichts, was uns hier interessieren muss. Was uns hier interessieren muss ist, was jetzt passiert. Ich rufe das auf und bekomme hier ein JSON-Array zurück. Dieses JSON-Array ist dann selber wieder ein JSON-Dokument, nur beginnt es halt mit eckigen Klammern. Darin befinden sich dann einzelne JSON-Objekte, immer begonnen und beendet durch die geschweiften Klammern und getrennt voneinander durch die Kommata. Auch hier können wir über den Accept-Header angeben, dass wir das Ganze lieber als XML haben wollen. Wenn ich das jetzt ausführe, bekomme ich es als XML zurück. Man sieht dann hier schon relativ überzeugend den Größenunterschied zwischen XML und JSON. Der Content Length Header, der uns vom Server zurückgegeben wird, besagt, an dieser Stelle beinhaltet das Dokument 680 Bytes. Bei dem Call davor war die Content Length also die Länge des Inhaltes für dieselben Inhalte, 271 Bytes. Das ist der Grund, warum man heutzutage häufig JSON zum Datenaustausch benutzt. und warum JSON im Grunde First Class Citizen von RESTful Services ist. In diesem Video haben wir uns damit auseinandergesetzt, was RESTful Services sind was JSON ist und was die JAX-RS für uns tun kann.

Java EE 7: Web Services

Steigen Sie ein in die Java-Enterprise-Welt und lernen Sie, wie Nachrichten ausgetauscht und Dienste definiert werden.

5 Std. 13 min (30 Videos)
Derzeit sind keine Feedbacks vorhanden...

Dieser Online-Kurs ist als Download und als Streaming-Video verfügbar. Die gute Nachricht: Sie müssen sich nicht entscheiden - sobald Sie das Training erwerben, erhalten Sie Zugang zu beiden Optionen!

Der Download ermöglicht Ihnen die Offline-Nutzung des Trainings und bietet die Vorteile einer benutzerfreundlichen Abspielumgebung. Wenn Sie an verschiedenen Computern arbeiten, oder nicht den ganzen Kurs auf einmal herunterladen möchten, loggen Sie sich auf dieser Seite ein, um alle Videos des Trainings als Streaming-Video anzusehen.

Wir hoffen, dass Sie viel Freude und Erfolg mit diesem Video-Training haben werden. Falls Sie irgendwelche Fragen haben, zögern Sie nicht uns zu kontaktieren!