seeseekey.net - Invictus Deus Ex Machina

Auf einem meiner Raspberry Pi-Rechner läuft eine in Mono geschriebene Server-Applikation. Damit die Server-Applikation funktionierte benötigte sie natürlich die Mono Runtime. Diese kann unter Raspbian einfach mittels des Kommandos:

apt-get install mono-runtime

installiert werden. Als ich die Serverapplikation nach der Installation von Mono ausführen wollte erhielt ich allerdings folgende Fehlermeldung:

Missing method .ctor in assembly Melinda.dll, type System.Runtime.CompilerServices.ExtensionAttribute
Can't find custom attr constructor image: Melinda.dll mtoken ...

Dieses Problem ließ sich durch die Installation der Bibliothek libmono-system-core4.0-cil beheben:

apt-get install libmono-system-core4.0-cil

Im Anschluss erhielt ich bei einem erneuten Startversuch eine weitere Fehlermeldung:

Grapevine.Exceptions.Server.UnableToStartHostException occurred
An error occured when trying to start the Grapevine.Server.RestServer

In diesem Fall kam die Fehlermeldung vom REST-API Framework Grapevine. Allerdings war der Fehler nicht wirklich in der Bibliothek zu finden. Stück für Stück kamen weitere Fehlermeldungen wie diese:

System.Reflection.ReflectionTypeLoadException: The classes in the module cannot be loaded.

zustande. Nach einiger Recherche war klar: auch in diesem Fall fehlten weitere Abhängigkeiten aus dem Mono-Framework. In diesem Fall half die Holzhammermethode; die Installation des kompletten Mono-Frameworks. Dazu wurde das Paket mono-complete mittels:

apt-get install mono-complete

installiert. Dieses nimmt ein paar mehr Megabyte als das Runtime-Paket in Anspruch, allerdings sind damit alle möglichen Abhängigkeiten installiert. Somit kann man sich auf die eigentliche Entwicklung und Ausführung der eigenen Applikationen konzentrieren, anstatt einer kuriosen Fehlermeldung nach der anderen hinter her zu jagen.

In den letzten Tagen habe ich für ein Projekt einen REST-Server geschrieben. Der Server läuft unter .NET bzw. Mono – also war ich auf der Suche nach einer passenden Bibliothek bzw. einem Framework, welches mich bei dem Aufsetzen eines solchen Servers unterstützt. Nach einem Blick auf Nancy und einigen anderen Frameworks bin ich schlussendlich bei Grapevine gelandet.

sukona.github.io

sukona.github.io

Dabei handelt es sich um eine Bibliothek, welche neben einem REST-Client auch einen REST-Server bereitstellt. Das Hauptaugenmerk der Entwicklung wird dabei auf den REST-Server gelegt. Mit Hilfe des Frameworks lässt sich ein REST-Server mittels weniger Zeilen Quellcode aufsetzen:

ServerSettings settings = new ServerSettings();
settings.Host = "localhost";
settings.Port = "1111";

RestServer server = new RestServer(settings);
server.Start();

In diesem Beispiel werden die Einstellungen für den Server angelegt und anschließend dem Server übergeben. Danach wird der Server mit der Methode Start hochgefahren. Damit verfügt man zwar über einen REST-Server, dieser verfügt allerdings über keinerlei Methoden was die praktische Verwendung eher erschwert. Ressourcen für den Server werden mittels des Attributes RestResource markiert:

[RestResource(BasePath = "/time/")]
public class TimeModule
{
    [RestRoute(PathInfo = "date")]
    public IHttpContext GetDate(IHttpContext context)
    {
        context.Response.SendResponse(Grapevine.Util.HttpStatusCode.Accepted, getDate());
        return context;
    }
}

Über das Attribut RestRoute wird eine Methode für Grapevine gekennzeichnet – das Pathinfo definiert dabei den Pfad über welchen diese aufgerufen werden kann. Durch den über das Attribut RestResource festgelegten BasePath lautet die vollständige URL für die Ressource:

http://localhost:1111/time/date

Wird diese Methode per GET aufgerufen, so wird das aktuelle Datum zurückgegeben. Damit ist ein minimaler REST-Server mit einer Ressource implementiert. Grapevine selbst ist unter der Apache Lizenz lizenziert und damit freie Software. Der Quelltext der Bibliothek befindet sich auf GitHub.

Bei WADL handelt es sich um die Web Application Description Language – eine Sprache mit der hauptsächlich REST-Services beschrieben werden. Auch wenn WADL in den letzten Jahren nicht mehr wirklich zum heißen Eisen gehört, wird es dennoch ab und an genutzt.

Ein WADL-Beispiel von Oracle.

Ein WADL-Beispiel von Oracle.

Möchte man eine solche WADL validieren, so kann man diese mit einem XML-Validator gegen das WADL-Schema validieren. Möglich ist dies z.B. mit folgendem Online-XML-Validator. Nachdem die zu überprüfende WADL im Validator eingetragen wurde, gibt man die URL:

https://www.w3.org/Submission/wadl/wadl.xsd

als Schema-URL an. Anschließend kann die XML-Datei gegen das XSD-Schema validiert werden.

Ein REST-API von Hand entwickelt, benötigt eine Dokumentation, ein entsprechenden Server und eventuell einige Clients als Referenz. Einfacher wird es mit einem Framework wie Swagger. Unter Zuhilfenahme der Beschreibungssprache YAML können mit Hilfe des Frameworks REST-APIs, Dokumentation, Server und Clients generiert werden.

Der Swagger Editor

Der Swagger Editor

Doch Swagger versteht sich nicht nur als Framework, sondern auch als Spezifikation. Begonnen wurde mit der Entwicklung bereits im 2010; die Swagger Specification trägt seit Anfang Januar 2012 offiziell den Namen OpenAPI Specification und beschreibt eine maschinenlesbare Interfacedefinitionen einer REST-API. Ähnliches wurde unter anderem schon mit WSDL und WADL versucht – alles Konzepte bzw. Beschreibungsprachen welche an ihren eigenen Limitationen gescheitert sind und wenn überhaupt nur noch sporadisch genutzt werden.

Betreut und weiterentwickelt wird die Spezifikation nun von der Open API Initiative, zu der namenhafte Firmen wie Google, PayPal, IBM, Atlassian und Microsoft gehören. Die Spezifikation als solche ist freie Software und auf GitHub zu finden. Sie ist unter der Apache Lizenz lizenziert. Aktuell ist die Spezifikation in der Version 2.0 veröffentlicht.

Auf der offiziellen Webseite von Swagger findet sich ein Editor, mit welchem APIs definiert werden können und anschließend exportiert werden können. Der Editor kann dabei Server unter anderem in den Sprachen bzw. für die Framworks Haskel, Jax-RS, Node.js, Python, Rails und PHP erzeugen. Bei den Clients ist die Auswahl noch größer. Diese können in C#, HTML, Dart, Go, Groovy, Java, Javascript, Objective C, Perl, PHP, Ruby, Scala, Swift und vielen weiteren Sprachen erzeugt werden.

Neben dem Editor kann für die Erzeugung von Clients auch der Swagger Codegen genutzt werden. Dabei handelt es sich um eine Java-Anwendung um die Clients lokal auf dem eigenen Rechner zu erzeugen. Der Editor und viele weitere Tools rund um Swagger sind ebenfalls auf GitHub zu finden. – auch diese sind freie Software, welche unter der Apache Lizenz stehen.

Wer eine REST– bzw. eine RESTful-API entwickeln möchte, der kann natürlich das Rad neu erfinden und die komplette API von Grund auf entwickeln. Einfacher wird es wenn man ein bestehendes Framework nutzt. Für diesen Zweck bietet sich unter PHP Restler an. Mit Hilfe dieses Frameworks lassen sich vollwertige REST-APIs innerhalb weniger Stunden entwickeln. So unterstützt Restler unter anderem unterschiedliche Ausgabeformate wie JSON, XML oder YAML. Abgerundet wird das Paket durch eine ausführliche Dokumentation und sehr viele gut dokumentierte Beispiele.

luracast.com/products/restler

luracast.com/products/restler

Restler ist unter der LGPL lizenziert und somit freie Software. Die offizielle Webseite ist mit hilfreichen Informationen gespickt, während der Quelltext auf GitHub zu finden ist.

Wer eine Rest-API testen möchte, der kann dies natürlich im Browser tun. Einfacher funktioniert das ganze mittels RESTClient. Dabei handelt es sich eine freie Anwendung um die REST-API aufzurufen und anschließend das Ergebnis auszuwerten.

RESTClient

RESTClient

Dabei hat man volle Kontrolle über die gesendeten Parameter, die HTTP Methode, den Header und einige andere Einstellungen. Nach einem ausgeführten Request können die Ergebnisse der Anfrage eingesehen werden. RESTClient ist unter der Apache Lizenz lizenziert. Neben der offiziellen Seite, gibt es den Download auf Foss Hub. Der Quelltext (sowie der Bugtracker) ist auf GitHub zu finden. Da RESTClient in Java entwickelt wurde ist es unter Linux, Mac OS X und Windows lauffähig.