REST-Server mit Grapevine aufsetzen

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.

Embedded Elasticsearch Server unter Java nutzen

Den freien Suchserver Elasticsearch kann man, wie das Wort Suchserver es dezent andeutet, als Server betreiben. Allerdings ist es manchmal nicht gewünscht einen dedizierter Server zu betreiben. In einem solchen Fall kann man den Elasticsearch-Server in eine Java-Applikation einbetten. Der sicherlich häufigste Fall für eine solche Einbettung ist dabei die Nutzung zu Testzwecken (z.B. Unit-Tests zum Test der Suchergebnisse). Im ersten Schritt sollte in das Java-Projekt die entsprechende Abhängigkeit zum Projekt hinzugefügt werden. In diesem Beispiel wird dabei auf einem auf Maven basierenden Projekt ausgegangen – in diesem muss die pom.xml entsprechend erweitert werden:

<dependency>
    <groupId>org.elasticsearch</groupId>
    <artifactId>elasticsearch</artifactId>
    <version>2.3.4</version>
</dependency>

Damit wurde Elasticsearch dem Projekt hinzugefügt. Nun muss der eigentliche Server im Java-Projekt gestartet werden. Dafür werden nur wenige Zeilen Quellcode benötigt:

Settings.Builder elasticsearchSettings = Settings.settingsBuilder()
    .put("http.enabled", "true")
    .put("path.data", "data")
    .put("path.home", "home");

Node node = nodeBuilder()
    .local(true)
    .settings(elasticsearchSettings.build())
    .node();

In diesem Beispiel werden im ersten Schritt die Einstellungen für Elasticsearch definiert. Dabei wird unter anderem der HTTP-Modus aktiviert. Wenn dieser deaktiviert ist, ist die Kommunikation per HTTP nicht mehr möglich. Stattdessen kann dann nur noch die Kommunikation über das Transport-Interface genutzt werden. Dieses Interface wird im Normalfall für die interne Kommunikationen zwischen einzelnen Elasticsearch-Clustern genutzt – allerdings ist eine Nutzung mit dem Elasticsearch-Java-Client ebenfalls möglich. Mit dem aktivierten Modus, ist die Entwicklung einfacher (z.B. für den Einsatz von Analyse-Tools) und die Konfiguration näher an der Praxis. Standardmäßig horcht der Elasticsearch-Server dabei auf dem Port 9200 – in diesem Beispiel wäre er über die URL:

http://localhost:9200

erreichbar. Nachdem die Einstellungen angelegt wurden, werden diese dem NodeBuilder übergeben, welcher schlussendlich den Elasticsearch-Server hochfährt. Nachdem dieser hochgefahren wurde, kann die Nutzung des selben beginnen.

Swagger – REST API goes Framework

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.

apt-get Sperrdateien entfernen

Unter Umständen kann es unter Ubuntu, oder anderen Distributionen basierend auf Debian passieren, das ein apt-get Vorgang fehlschlägt. Dies kann sich darin äußern das apt-get nicht mehr genutzt werden kann – stattdessen bekommt man folgende Meldung zu sehen:

E: Could not get lock /var/lib/dpkg/lock - open (11 Resource temporarily unavailable)
E: Unable to lock the administration directory (/var/lib/dpkg/) is another process using it?

Hintergrund ist das dpkg Sperrdateien mit dem Name lock anlegt und sie nach getaner Arbeit wieder entfernt. Bei plötzlichen Unterbrechungen wie z.B. einem Stromausfall kann es passieren das die Dateien nicht mehr entfernt werden. Lösen kann man das Problem indem man die entsprechenden Sperrdateien entfernt:

rm /var/lib/dpkg/lock
rm /var/lib/apt/lists/lock
rm /var/cache/apt/archives/lock

Abschließend sollte dpkg bzw. apt-get wieder ohne Probleme funktionieren.

Probleme mit dem Minecraft Server, Ubuntu 16.04 und KVM

Vor einigen Tagen migrierte ich einen Minecraft-Server von einem Server mit Ubuntu 14.04 LTS auf einen Server mit Ubuntu 16.04 LTS. Der Minecraft-Server lief dabei auf dem alten als auch auf dem neuen Server jeweils in einer KVM-Gast-Maschine. Er startete ohne Probleme und wenn man sich das ganze von außen mit nmap anschaute, war der entsprechende Port auch offen gekennzeichnet. Allerdings konnte der Minecraft-Client keinerlei Verbindung mit dem Server aufnehmen. Lösen ließ sich das Problem mit der Änderung einer Einstellung in der server.properties Datei. Konkret ging es dabei um die Einstellung:

use-native-transport = true

welche auf false gesetzt werden musste. Mit diesem Flag wird das optimierte Senden und Empfangen von Paketen unter Linux deaktiviert. Damit funktionierte der Minecraft-Server wieder ohne Probleme.