Hier is een voorstel voor het ontwerpen van een mock API die multi-tenant architectuur ondersteunt met geïsoleerde datascopes: 1. API-structuur en tenant-identificatie - Elke API-aanroep moet de header `Authorization` bevatten met de tenant-ID, bijvoorbeeld: `Authorization: Tenant-ID: <tenant-id>` - Bij elke request wordt de tenant-ID uit de header gehaald en gebruikt om de gegevensscope te bepalen. 2. Endpoints en datasegregatie - `/gebruikers` - `/projecten` Voorbeeld van GET, POST, PUT, DELETE methoden: **GET /gebruikers** ```json { "gebruikers": [ { "id": "gebruiker1", "naam": "Jan", "tenant": "<tenant-id>" }, ... ] } ``` - Alleen gebruikers die bij de tenant horen worden weergegeven. **POST /gebruikers** - Alleen toegestaan voor tenants, met validatie dat de gebruiker wordt toegevoegd aan de juiste tenant. **GET /projecten** - Alleen projecten van de betreffende tenant worden weergegeven. **PUT /projecten/{project-id}** en **DELETE /projecten/{project-id}** - Alleen voor tenant-eigen projecten, en alleen voor users met admin-rechten. 3. Rollen en toegangscontrole - Implementeer in de mock API een eenvoudige role-toewijzing, bijvoorbeeld via header `X-Role: admin` of `X-Role: user`. - Bij bewerkingen: - `admin` kan projecten bewerken, verwijderen, toevoegen. - `user` kan alleen lezen. 4. Voorbeeld van toegangscontrole: ```plaintext if role == "admin" then toestaan bewerking else indien bewerking == 'lezen' dan toestaan anders fout 403 ``` 5. Simuleren van tenant-specifieke foutscenario's - Fout 401: ongeldige of ontbrekende tenant-ID-header - Fout 403: toegang geweigerd (bijvoorbeeld niet-authorized acties) - Fout 404: resource niet gevonden (bijvoorbeeld niet-behorende tenant) - Fout 500: interne serverfout (bijvoorbeeld simuleer door een flag) **Voorbeeld:** ```json { "error": "Tenant-ID header ontbreekt", "status": 401 } ``` 6. Data-consistentiechecks - Controleer dat bij het aanmaken of updaten van gegevens de tenant-ID overeenkomt met de scope van de request. - Bij het verwijderen of bijwerken van resources, controleer dat de resource daadwerkelijk bij de tenant hoort. - Implementeer logs of waarschuwingen bij inconsistenties om deze te detecteren. 7. Aanvullende suggesties - Gebruik in je mock API een in-memory database (bijvoorbeeld JSON-objecten) gescheiden per tenant. - Maak mock data voor verschillende tenants, bijvoorbeeld tenant A en tenant B, met eigen gebruikers en projecten. - Voeg endpoints toe voor het resetten van data of het toevoegen van tenants voor testdoeleinden. **Voorbeeld van data structuur:** ```json { "tenants": { "tenantA": { "gebruikers": [...], "projecten": [...] }, "tenantB": { "gebruikers": [...], "projecten": [...] } } } ``` Met dit ontwerp krijg je een flexibele en realistische mock API die multi-tenant kenmerken, datasegregatie, toegangscontrole en foutscenario's effectief simuleert.

Hier is een ontwerp voor een mock API met multi-tenant ondersteuning: ## API Basisstructuur ```yaml Base URL: /api/v1 Authenticatie: Bearer {tenant-id} Endpoints: - GET /gebruikers - GET /gebruikers/{id} - GET /projecten - GET /projecten/{id} - POST /projecten - PUT /projecten/{id} - DELETE /projecten/{id} ``` ## Tenant Identificatie ```javascript // Middleware voor tenant-extractie const tenantMiddleware = (req, res, next) => { const authHeader = req.headers.authorization; if (!authHeader || !authHeader.startsWith('Bearer ')) { return res.status(401).json({ error: 'Tenant-ID vereist in Authorization header' }); } const tenantId = authHeader.replace('Bearer ', ''); req.tenant = tenantId; next(); }; ``` ## Mock Data Structuur ```json { "tenants": { "tenant-001": { "gebruikers": [ {"id": 1, "naam": "Jan Jansen", "rol": "admin", "email": "jan@tenant-001.nl"}, {"id": 2, "naam": "Marie Peters", "rol": "gebruiker", "email": "marie@tenant-001.nl"} ], "projecten": [ {"id": 1, "naam": "Website Redesign", "eigenaar": 1, "status": "actief"}, {"id": 2, "naam": "Database Migratie", "eigenaar": 1, "status": "voltooid"} ] }, "tenant-002": { "gebruikers": [ {"id": 1, "naam": "Piet Bakker", "rol": "admin", "email": "piet@tenant-002.nl"}, {"id": 2, "naam": "Lisa de Vries", "rol": "gebruiker", "email": "lisa@tenant-002.nl"} ], "projecten": [ {"id": 1, "naam": "Mobile App", "eigenaar": 1, "status": "in ontwikkeling"} ] } } } ``` ## Toegangscontrole Implementatie ```javascript // Gebruikers endpoint app.get('/gebruikers', tenantMiddleware, (req, res) => { const tenantData = mockData.tenants[req.tenant]; if (!tenantData) { return res.status(404).json({ error: 'Tenant niet gevonden' }); } res.json(tenantData.gebruikers); }); // Projecten endpoint met permissies app.get('/projecten', tenantMiddleware, (req, res) => { const tenantData = mockData.tenants[req.tenant]; res.json(tenantData.projecten); }); app.post('/projecten', tenantMiddleware, (req, res) => { const gebruiker = getCurrentUser(req); // Helper functie if (gebruiker.rol !== 'admin') { return res.status(403).json({ error: 'Alleen admins kunnen projecten aanmaken' }); } // Project aanmaak logica }); ``` ## Tenant-specifieke Foutscenario's ### 1. Onbekende Tenant ```javascript // Simuleer ongeldige tenant app.use('/api/*', (req, res, next) => { if (Math.random() < 0.1) { // 10% kans op fout return res.status(404).json({ error: 'Tenant niet gevonden', tenantId: req.tenant, code: 'TENANT_NOT_FOUND' }); } next(); }); ``` ### 2. Quota Limieten ```javascript // Simuleer quota overschrijding app.post('/projecten', (req, res, next) => { const tenantData = mockData.tenants[req.tenant]; if (tenantData.projecten.length >= 5) { // Max 5 projecten return res.status(429).json({ error: 'Project limiet bereikt', huidigAantal: tenantData.projecten.length, maximum: 5, code: 'QUOTA_EXCEEDED' }); } next(); }); ``` ### 3. Dataconsistentie Checks ```javascript // Valideer tenant-specifieke relaties app.post('/projecten', (req, res) => { const { naam, eigenaar } = req.body; const tenantData = mockData.tenants[req.tenant]; // Check of eigenaar bij tenant hoort const gebruikerExists = tenantData.gebruikers.some(u => u.id === eigenaar); if (!gebruikerExists) { return res.status(400).json({ error: 'Ongeldige gebruiker voor project', details: 'Gebruiker behoort niet tot deze tenant', code: 'INVALID_USER_REFERENCE' }); } // Duplicaat check const duplicateProject = tenantData.projecten.find(p => p.naam === naam); if (duplicateProject) { return res.status(409).json({ error: 'Projectnaam bestaat al', conflictId: duplicateProject.id, code: 'DUPLICATE_RESOURCE' }); } }); ``` ## Aanvullende Suggesties ### 1. Tenant Configuratie ```javascript const tenantConfigs = { 'tenant-001': { maxProjects: 10, features: ['advanced_analytics'] }, 'tenant-002': { maxProjects: 5, features: ['basic'] } }; ``` ### 2. Audit Logging ```javascript // Log alle tenant-acties const auditLogger = (req, action) => { console.log(`[TENANT:${req.tenant}] ${action} - ${new Date().toISOString()}`); }; ``` ### 3. Rate Limiting per Tenant ```javascript const rateLimits = new Map(); app.use((req, res, next) => { const tenant = req.tenant; const now = Date.now(); const window = 60000; // 1 minuut if (!rateLimits.has(tenant)) { rateLimits.set(tenant, { count: 0, startTime: now }); } const tenantLimit = rateLimits.get(tenant); if (now - tenantLimit.startTime > window) { tenantLimit.count = 0; tenantLimit.startTime = now; } if (tenantLimit.count >= 100) { // 100 requests per minuut return res.status(429).json({ error: 'Rate limit exceeded' }); } tenantLimit.count++; next(); }); ``` ### 4. Test Scenario's voor Developers ```bash # Geldige tenant curl -H "Authorization: Bearer tenant-001" /api/gebruikers # Ongeldige tenant curl -H "Authorization: Bearer unknown-tenant" /api/gebruikers # Gebruiker probeert project aan te maken curl -X POST -H "Authorization: Bearer tenant-001" /api/projecten # (met gebruiker token zonder admin rechten) ``` Dit ontwerp biedt een robuuste basis voor het testen van multi-tenant functionaliteit met geïsoleerde datascopes en realistische foutscenario's.