Slim Framework

Für wahrscheinlich jede Programmiersprache existieren mehr oder weniger viele Frameworks, welche dem Entwickler bestimmte Aufgaben abnehmen und somit die Entwicklung beschleunigen. Neben den größeren Framework existieren auch eine Reihe von Frameworks mit einem minimalistischeren Ansatz. Eines dieses sogenannten Microframeworks ist Slim. Entwickelt wird und wurde Slim für PHP.

slimframework.com

Slim eignet sich sehr gut für die Umsetzung für REST-APIs bzw. RESTful Webservices. Um ein Projekt zu erstellen, kann der Paket- bzw. Dependency-Manager Composer genutzt werden:

composer create-project slim/slim-skeleton exampleapp

Damit wird ein Grundprojekt angelegt mit welchem gearbeitet werden kann. Auch von seitens des Swagger-Toolings wird Slim unterstützt. So kann eine API über den Swagger-Editor definiert werden und anschließend für das Slim-Framework exportiert werden. Der Quelltext des Frameworks ist auf GitHub zu finden. Es ist unter MIT-Lizenz lizenziert und damit freie Software. Die offizielle Seite des Projektes ist unter slimframework.com zu finden.

REST-APIs unter Apache und Nginx betreiben

Eine der wesentlichen Eigenschaften von REST-APIs bzw. RESTful-Webservices ist ihre Adressierbarkeit von Ressourcen. Wenn ich z.B. über eine API verfüge, welche mir Namen generiert, so kann es in dieser API unterschiedliche Ressourcen geben:

GET https://api.example.com/name/german/
GET https://api.example.com/name/polish/

Rufe ich nun eine der beiden Ressourcen mit dem HTTP-Verb GET auf so erhalte ich entweder einen deutschen oder einen polnischen Namen von dieser Beispiel-API. Für den Webserver ergibt sich allerdings das Problem, das der Ordner name und die entsprechenden Unterordner nicht existieren. Das einzige was in diesem Beispiel existiert ist eine index.php-Datei, welche unter der URL:

https://api.example.com/index.php

zu finden ist. Damit die REST-API ordnungsgemäß funktioniert, müssen die entsprechenden Aufrufe zur index.php-Datei umgebogen werden. Bei dem Webserver Apache kann dies über eine .htaccess-Datei mit folgendem Inhalt erledigt werden:

<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteRule ^(.*)$ index.php?_url=/$1 [QSA,L]
</IfModule>

Diese Datei sollte dabei im gleichen Verzeichnis wie die Datei index.php liegen. Bei Nginx muss stattdessen die Konfiguration der Domain bzw. der Seite angepasst werden. Diese Konfigurationen sind unter /etc/nginx/sites-available/ zu finden. Dort muss folgende Konfiguration hinzugefügt werden:

try_files $uri $uri/ @rewrite;

location @rewrite {
	   rewrite ^/(.*)$ /index.php?_url=/$1;
}

Hinterlegt werden muss die Konfiguration in einem server-Block derselben. In diesem Fall würde die URL bzw. der Aufruf:

GET https://api.example.com/name/german/

intern in die URL:

https://api.example.com/index.php?_url=name/german/

umgeschrieben und vom Webserver geladen. Dadurch landen die Aufrufe wieder bei der Datei index.php und können verarbeitet werden.

API-Kataloge im Web

Jeder und kleinere und größere Webdienst verfügt mittlerweile über eine API, meist ausgeführt in Form eines RESTful-Webservice. Interessant ist es natürlich zu schauen, welche APIs öffentlich verfügbar sind. Hierbei helfen entsprechende Kataloge wie AnyAPI, welcher unter any-api.com zu finden ist. Dieser bietet Informationen über 1400 öffentlich zugängliche APIs.

Any API listet über 1400 öffentlich zugängliche APIs

Die APIs bei AnyAPI sind nach Kategorien geordnet. Zu jeder API finden sich in dem Katalog die Auflistung der Ressourcen und Dokumentation zur Nutzung der API. Daneben existieren weitere Kataloge wie die API List oder die Public APIs-Sammlung. Letztere wiederrum verfügt über eine API zum Abruf der APIs.

LoadingCache der Guava-Bibliothek nutzen

Für Java existiert eine Bibliothek mit dem Namen Guava. Diese, von Google entwickelte, Bibliothek bietet gewisse Basisfunktionalitäten, welche vom Java-Framework nicht abgedeckt werden. Eine dieser Funktionalitäten ist der LoadingCache. Bei diesem handelt es sich um einen Cache, welcher dazu genutzt werden kann die Ergebnisse zeitintensiver Operationen zwischenzuspeichern. Daneben verfügt er über die Informationen wie er die entsprechenden Daten bezogen werden. Um Guava zu nutzen muss die Bibliothek z.B. mittels Maven eingebunden werden. Dazu muss die pom.xml-Datei um eine Abhängigkeit erweitert werden:

<dependency>
	<groupId>com.google.guava</groupId>
	<artifactId>guava</artifactId>
	<version>27.0-jre</version>
</dependency>

Anschließend kann Guava in dem betreffenden Projekt genutzt werden. In diesem Beispiel soll der Cache dazu dienen Anfragen an einen Webservice zu cachen. Der Webservice liefert Daten zurück, welche in einem Objekt vom Typ BookData gespeichert werden:

class BookData {

	public final String title;
	public final String description;
	public final double price;

	public BookData(String title, String description, double price) {
		this.title = title;
		this.description = description;
		this.price = price;
	}
}

Innerhalb der Anwendung übernimmt die Methode getBookData die Aufgabe, diese Daten vom Webservice zu beziehen:

public BookData getBookData(String isbn) {
	return bookdataService.getData(isbn);
}

Der LoadingCache von Guava ist technisch betrachtet eine Map. Bei der Initialisierung ist dies ersichtlich:

LoadingCache<String, BookData> books = CacheBuilder.newBuilder()
		.maximumSize(1000)
		.expireAfterWrite(7, TimeUnit.DAYS)
		.build(
				new CacheLoader<String, BookData>() {
					public BookData load(String isbn) {
						return getBookData(isbn);
					}
				});

Beim Anlegen des Cache können unterschiedliche Parameter wie die maximale Größe, die Zeit ab der ein Eintrag erneuert wird und der CacheLoader definiert werden. Der CacheLoader implementiert die Methode load, welche die entsprechenden Daten vom Webservice bezieht. Nachdem der LoadingCache definiert ist, kann die Map normal genutzt werden:

BookData bookData = books.get("9783736889842");

Im Hintergrund wird der Wert, wenn vorhanden, aus dem Cache bezogen. Ist dies nicht der Fall wird stattdessen der CacheLoader genutzt, welcher in diesem Beispiel einen Request an den Webservice sendet und das Ergebnis wieder im Cache hinterlegt. Der LoadingCache selber beschränkt sich auf die Laufzeit der Applikation und wird nicht persistiert.