Header in Postman von Tab zu Tab übernehmen

Mit der App Postman ist es möglich REST-API Aufrufe gegen beliebige Endpunkte durchzuführen. Wenn man nun bei einem Reponse auf einen Link klickt, so öffnet sich innerhalb von Postman ein neuer Tab mit dem Link als URL. Leider werden die Header des aktuellen Tabs dabei nicht übernommen. Wenn man sich innerhalb einer API bewegt, kann dieses Verhalten von Postman ziemlich anstrengend sein, da die Header dann immer wieder von Tab zu Tab kopiert werden müssen.

Die Einstellungen von Postman

Abhilfe schaffen hier die Einstellungen von Postman. In diesen befindet sich im Tab General der Punkt Retain headers when clicking on links. Sobald diese Einstellung aktiviert ist, werden bei einem neuen Tab, welcher durch einen Klick auf einen Link entsteht, automatisch die Header vom alten Tab in den neuen Tab übertragen.

Google Fonts herunterladen

Im Rahmen der DSGVO wird unter anderen Datensparsamkeit gefordert; bei vielen Webseiten ist dies leider nicht immer gegeben. So findet häufig die Einbindung der Google Fonts vor. Jetzt ist es per se nicht verwerflich Google Fonts zu nutzen, allerdings sollten diese Fonts lokal eingebunden werden. Wenn dies nicht geschieht und sie direkt über das CDN von Google eingebunden werden, überträgt man bei jedem Aufruf entsprechende Daten an Google.

fonts.google.com

Um dies zu unterbinden, sollte die gewünschte Schriftart heruntergeladen werden und anschließend lokal in die eigene Webseite bzw. das eigene Projekt eingebunden werden. Hierfür bietet sich der google-webfonts-helper von Mario Ranftl an. Dort wählt man die gewünschte Schriftart aus und kann diese anschließend herunterladen. Neben dem eigentlichen Font wird auch entsprechendes CSS zu Einbindung bereitgestellt. Genutzt werden kann der google-webfonts-helper nicht nur über die Weboberfläche, sondern auch über eine entsprechende REST-API.

Der google-webfonts-helper

Der Quelltext des google-webfonts-helper kann über GitHub bezogen werden. Lizenziert ist das Projekt unter der MIT Lizenz und damit freie Software.

Bibliothek zur Nutzung der MediaWiki-API unter .NET

Für ein kleines Projekt war ich auf der Suche nach einer halbwegs aktuellen Bibliothek zur Nutzung der MediaWiki-API. Wenn man sich auf der entsprechenden Seite in der MediaWiki-Dokumentation umschaut, wird man feststellen das einem nicht all zu viele Bibliotheken zur Verfügung stehen.

Die Auswahl an .NET Bibliotheken fällt eher mager aus

Genutzt habe ich letztendlich die Bibliothek Wiki Client Library, da diese halbwegs aktuell ist und mit meinen MediaWiki-Installationen problemlos zusammenarbeitet. Ein minimales Beispiel zur Bearbeitung einer Wiki-Seite sieht mit der Bibliothek wie folgt aus:

// Init
var client = new WikiClient
{
    ClientUserAgent = "WikiBot"
};

var site = new WikiSite(client, https://wiki.example.com/api.php);

// Login
await site.Initialization;
try
{
    await site.LoginAsync("username", "password");
}
catch (WikiClientException ex)
{
    Console.WriteLine(ex.Message);
}

// Edit site
var page = new WikiPage(site, buildingName);

// Load page
await page.RefreshAsync(PageQueryOptions.FetchContent);

// Update page
page.Content = "new content";
await page.UpdateContentAsync("New page created.", minor: false, bot: true);

// Logout
await site.LogoutAsync();

Über die Nutzung von Generatoren ist es möglich größere Bereiche wie z.B. Kategorien oder Suchergebnisse zu iterieren:

// Iterate all pages
var generator = new AllPagesGenerator(site)
{
    StartTitle = "A",
    NamespaceId = BuiltInNamespaces.Main,
    PaginationSize = 50
};

using (var enumerator = generator.EnumPagesAsync().GetEnumerator())
{
    int index = 0;

    while (await enumerator.MoveNext(CancellationToken.None))
    {
        // Debug output
        var page = enumerator.Current;
        Console.WriteLine("{0}: {1}", index, page);
        index++;

        // Load page
        await page.RefreshAsync(PageQueryOptions.FetchContent);

        // Update page
        page.Content = "new content";
        await page.UpdateContentAsync("Update page.", minor: true, bot: true);
    }
}

Der Quelltext der Wiki Client Library ist auf GitHub zu finden. Lizenziert ist er unter der Apache Licence 2 und damit freie Software.

Domänenspezifische Sprache für Tests von REST-Schnittstellen

Eine domänenspezifische Sprache, kurz DSL, ist eine auf ein bestimmtes Problemfeld abgestimmte Sprache. Mit dem freien REST Assured existiert eine solche Sprache für den effektiven Test von REST-Schnittstellen. Genutzt wird REST Assured hauptsächlich unter Java und Groovy. Eine einfache Überprüfung des Statuscodes einer API-Anfrage würde in REST Assured wie folgt aussehen:

given().get("api.example.com").then().assertThat().statusCode(200);

Daneben sind auch komplexe Tests wie die Auswertung von zurückgegebenen JSON-Strukturen und Daten, sowie die Verknüpfung unterschiedlicher Bedingungen ohne Probleme zu implementieren. Eine große Übersicht über die Möglichkeiten von REST Assured bietet der Usage-Guide des Projektes.

rest-assured.io

Die Projektseite von REST Assured ist unter rest-assured.io zu finden. Der unter der Apache Lizenz (Version 2.0) lizenzierte Quellcode kann auf GitHub gefunden werden.

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.