img - GitHub Pages

4.2. RP1 REST 59
Das Beispiel im Quelltext 4.1 zeigt zwei Definitionen einer API-Route.
23 var controller = require('./controller')
24 , basicAuthentication = require('../policy/basicAuthentication')
25 , authorizedForCommunity = require('../policy/authorizedForCommunity')
26 , communityValidators = require('./validators')
27 , utils = require('../utils')
28 , modulePrefix = '/community';
29
30 module.exports = function initCommunityApi(api, apiPrefix) {
31 var prefix = apiPrefix + modulePrefix;
32
33 // GET /api/community/:id
34 api.get(prefix + '/:id(\\d+)', [
35 basicAuthentication
36 , authorizedForCommunity
37 , controller.getCommunityWithId]);
38
39 // GET /api/community/:slug
40 api.get(prefix + '/:slug', [
41 basicAuthentication
42 , authorizedForCommunity
43 , controller.getCommunityWithSlug]);
44
45 // POST /api/community
46 api.post(prefix, [
47 basicAuthentication
48 , communityValidators.createCommunity
49 , controller.createCommunity
50 ]);
51 //...
52 };
Quelltext 4.1: Community API Definition [AJWi]
Bei Zeile 34 wird eine “GET” API-Methode für das Abfragen einer Community mit
der ID definiert. Wie man im definierten Array sieht, werden dabei mehrere Callbacks
definiert, welche der Reihe nach aufgerufen werden und sicherstellen, dass jede Anfrage
authentifiziert und autorisiert ist.
Zeile 46 definiert eine “POST” API-Route um eine neue Community zu erstellen.
Auch hier wird überprüft ob der Benutzer authentifiziert ist. Zusätzlich wird ein Daten-
Validator verwendet, damit sichergestellt werden kann dass die Daten korrekt und ohne
unerwünschte Zeichen sind.
Aus Zeitgründen wurde kein Caching und keine Versionierung implementiert.
Eine Versionierung wäre durch ein zusätzliches Präfix für die API-Routes problemlos
möglich.
Dasselbe gilt für das Caching. Jedes Objekt in der Datenbank hat eine Spalte mit
der Information, wann es zuletzt modifiziert wurde. Durch diese Information kann ein
generisches Caching implementiert werden.