In der vorherigen Ausgabe ging es um die ersten Schritte in der Bereitstellung eines Rest-Webservices. In dieser Ausgabe sollen die weiteren Teilschritte in der Webservice-Bereitstellung erläutert werden. Die „URI-Pfadvorlage für die Methode“ dient dem Zuordnen der Anforderungen zu den Anforderungsmethoden. Im Beispiel wird dieser Parameter auf dem Standardwert *NONE gelassen.

Die unterschiedlichen Parameter in dieser Anzeige sind folgende:

• Procedure Name: Name der Prozedur. Dieser wurde durch die bisherigen Eingaben bereits voreingestellt.

• URI Path Template for Resource: Hier ist die URI-Pfadschablone für die Ressource anzugeben.

• HTTP-Anforderungsmethode: Hier muss die HTTP-Anforderungsmethode angegeben werden. Als Standardwert für diesen Parameter ist „GET“ voreingestellt. Über das Selektionssymbol kann zudem zwischen den folgenden Anforderungsmethoden gewählt werden:

o GET

o PUT

o DELETE

o POST

• URI-Pfadvorlage für die Methode:

Die URI-Pfadvorlage für die Methode dient dem Zuordnen von Anforderungen zu den Ressourcenmethoden.

• HTTP Response Code Output Parameter:

Hier kann ein Ausgabeparameter vorgegeben werden, der den HTTP-Antwortcode aufnimmt, womit wiederum auf die unterschiedlichen HTTP-Ergebnisse reagiert werden kann. Der Parameter ist zwingend als Integer-Wert anzugeben.

• HTTP Header Array Output Parameter:

Optional kann ein Ausgabeparameter für die Aufnahme von HTTP-Headern definiert werden, die an den Client übertragen werden. Wird dieser Parameter gewünscht, dann muss er als Array (Char) angelegt werden.

• Zulässige Eingabemedien:

Hier können die zulässigen MIME-Typen hinterlegt werden, die mit der Ressourcenmethode verarbeitet werden dürfen.

Entweder übernehmen Sie den Standardwert „*ALL“ oder selektieren im Auswahlfenster die gewünschten Eingabemedien. Gültige Werte sind:

o *ALL

o *XML

o *JSON

o *XML_and_JSON

• Zurückgegebene Ausgabemedientypen:

Es sind die MIME-Typen zu hinterlegen, die bei der Ressourcenmethode zurückgegeben werden sollen.

• Whether to Wrap Input Parameters:

Dieser Wert definiert, ob die Eingabeparameter in einer Struktur übergeben werden.

Klicken Sie nach der Eingabe der erforderlichen Parameter auf „Weiter“.

In der nächsten Anzeige muss der Benutzer angegeben werden, unter dem der Service auf dem System i ausgeführt werden soll. Dabei kann wahlweise die Benutzer-ID, mit der der Server ausgeführt wird, ein existierender IBM-i-Benutzer angegeben werden. Diese Angabe wirkt sich unter anderem auf die Objektberechtigungsprüfung aus. Deshalb ist es sinnvoll und wichtig, hier einen Benutzer anzugeben, der auf dem System i für die Ausführung der Programme über die notwendigen Berechtigungen verfügt.

Es folgt wieder ein Klick auf die Schaltfläche „Weiter“.

Analog der Bibliotheksliste in einem Job muss nun angegeben werden, welche Bibliotheken in welcher Reihenfolge für die erfolgreiche Ausführung des Jobs benötigt werden. Diese Bibliotheken sind in der nachfolgenden Anzeige zu definieren.

IBM stellt an dieser Stelle bereits die Bibliothek ein, in der sich das basierende (Service-)Programm befindet, das für den Webservice Pate steht. Mit einem Klick auf die Schaltfläche „Hinzufügen“ können anschließend weitere Bibliotheken angegeben werden. Allerdings muss darauf geachtet werden, dass die Bibliotheksliste sowohl in Bezug auf die Bibliotheken als auch in Bezug auf die Reihenfolge genau festzulegen ist.

Es folgt abermals ein Klick auf die Schaltfläche „Weiter“.

Die für den Rest-Webservice erforderlichen Angaben sind nun komplettiert. Mit einem Klick auf die Schaltfläche „Fertig stellen“ wird der Webservice auf dem Server angelegt.

Temporär erscheint die Implementierungsanzeige mit dem Status „Wird installiert“.

Jetzt muss nur noch sichergestellt sein, dass der neu implementierte Webservice auch gestartet ist. Dies ist am Status (gestartet) und dem grünen Symbol erkennbar.

Zuletzt heißt es den Service testen. Dazu klicken Sie auf die Schaltfläche „Service testen“, die Sie bereits von den Soap-Webservices her kennen. Sie werden sich wundern, denn die Schaltfläche ist deaktiviert. Und zwar nicht aufgrund des Vorgehens, nein, es ist so, dass zwar ein Soap-Webservice auf System i mit dem integrierten Test-Client auf seine Funktion hin geprüft werden kann, nicht jedoch im Zusammenhang mit den Rest-Webservices. Nichtsdestotrotz, nutzen Sie einfach die Stärke der Rest-Webservices, denn diese verwenden schlicht eine HTTP-Get-Methode, die mit jedem gängigen Browser simuliert bzw. genutzt werden kann.

Öffnen Sie also ein neues Browser-Fenster und geben dort die URL für den neuen Webservice an. Im Falle, dass Sie diese nicht wissen, können Sie sie in den Eigenschaften des neuen Webservices schnell finden. Schauen Sie sich dazu folgende Abbildung an.

Der Parameter „Base resource URL“ beinhaltet die Aufruf-URL, allerdings ohne den notwendigen Eingabeparameter. Diesen müssen Sie bei der URL-Eingabe mitberücksichtigen bzw. eingeben. Für die Ermittlung des Celsius-Werts für 50 Grad Fahrenheit zum Beispiel wäre dies die folgende URL:

10.1.2.125:10010/web/services/Temperartur/50

Nach dem Bestätigen der Eingabe wird der Rest-Webservice auf dem System i aufgerufen. Allerdings ist das Ergebnis nicht sofort ersichtlich, sondern es erscheint ein Hinweis mit der Frage, ob das JSON-Format gespeichert oder geöffnet werden soll.

In diesem Fall soll das Ergebnis nur geöffnet werden, weshalb die Option „Öffnen“ gewählt wird.

Für die JSON-Ergebnisanzeige können unterschiedliche Tools genutzt werden. Im Beispiel genügt die Anzeige in Notepad, weshalb Notepad als Anwendung selektiert wird. Damit erhalten Sie die Anzeige des Ergebnisses des Rest-Webservice-Aufrufs.

In der Ergebnisanzeige finden Sie den Parameternamen und den ermittelten Wert.

Demzufolge sind 50 Grad Fahrenheit 10 Grad Celsius. Dass IBM hier 9,99 zurückliefert, bietet vielleicht den Anlass für ein PTF…