REST-Api mit dem Caddyserver simulieren

Ja, ich bin ein Fanboy. Ja, der bin ich gerne, wenn das „Produkt“ oder Projekt sinnvoll und inspirierend ist. Ich arbeite zum Beispiel in Teams, bei denen jeder Entwickler eigener Herr seiner Maschine ist und ich exakt nichts voraussetzen kann, was jemand auf seinem Rechner installiert hat, wo er es hat und wie es konfiguriert ist.

Wenn man SPAs entwickelt, kann man natürlich für eine reine Frontend-Entwicklung eine komplette Vagrant-Box aufsetzen. Das ergibt für das Backend-Team einfach mehr Sinn. Da nicht jeder über eine generische Umgebung für den Apachen verfügt und das unter Windows z.B. auch eher suboptimal läuft, war ich total begeistert als ich über den Caddyserver gestolpert bin: „Serve the web like it’s 2016“. Caddy hat Binaries für Windows, Linux und OSX und braucht nur ein ziemlich einfaches Konfig-File.

Damit ist ein zweiter Entwickler ohne viel Stress in der Lage, ein SPA-Projekt zu übernehmen. Er braucht die Entwicklungs-Tools und den Caddyserver. Unsere aktuellen SPA-Projekte haben diese Datei schon von mir verpasst bekommen, in der Regel mit Proxy-Rewrites. die auf die Maschine mit dem Backend zeigen.

Aber man kann in den frühen Phasen des Projekts auch eine API und die entsprechenden REST-Requests mit lokalen JSON-Dateien simulieren, damit kann auch ein Abzug einer API lokal statisch genutzt werden. Das ist z.B. bei der Entwicklung von SPAs mit AngularJS oder EmberJS praktisch.

Ein GET-Request an /api/test/eintest  wird damit auf die Datei /data/get_test_eintest.json umgeleitet. Auch Antworten eines Post-Requests lassen sich mit /data/post_test.json simulieren.

Weitere Doku:

Code für einen lokalen API-Abzug in JSON-Files

:9090
gzip
rewrite /api {
	r ^/(.*?)/(.*?)/(.*?)/(.*?)/(.*?)(/|)$
	to /data/{method}_{1}_{2}_{3}_{4}_{5}.json
}
rewrite /api {
	r ^/(.*?)/(.*?)/(.*?)/(.*?)(/|)$
	to /data/{method}_{1}_{2}_{3}_{4}.json
}
 
rewrite /api {
	r ^/(.*?)/(.*?)/(.*?)(/|)$
	to /data/{method}_{1}_{2}_{3}.json
}
 
rewrite /api {
	r ^/(.*?)/(.*?)(/|)$
	to /data/{method}_{1}_{2}.json
}
 
rewrite /api {
	r ^/(.*?)(/|)$
	to /data/{method}_{1}.json
}

Das ganze kann ich auch gerne noch mal als .htaccess-Datei für den Apachen zur Verfügung stellen.

2 Kommentare » Schreibe einen Kommentar

  1. Hi,
    nette idee -> doch wie sieht es mit httpstatuscodes, parametern z.B. token, filter und pageing aus?

    • Da lasse ich mich gerne mit einer tollen Idee überzeugen. Für ausgefeiltere API-Mocks sind ggf Dienste wie Apiary sinnvoller.

      Für den ersten Step der Anwendung sollte das aber durchaus reichen.