settings
OTEX_BIG
Süddeutsche Zeitung Institut Auszeichnung
Image
Alle Weitere Themen Schulungen

Schulung REST API Design: Ressourcen, Konventionen und Best Practices

Gute APIs entwerfen: Naming, Versionierung, Fehlerbehandlung und Hypermedia

2 Tage / S6812
Neues Seminar
Per E-Mail senden

Schulungsformen

Inhouse-/Firmenschulung

  • 2 Tage - anpassbar
  • Termin nach Wunsch
  • In Ihrem Hause oder bei der GFU
  • Preis nach Angebot
  • Lernumgebung in der Cloud
  • Inhalte werden auf Wunsch an die Anforderungen Ihres Teams angepasst.
Präsenz Online Hybrid
Unverbindlich anfragen

Individualschulung

  • 2 Tage - anpassbar
  • Termin nach Wunsch
  • In Ihrem Hause oder bei der GFU
  • Preis nach Angebot
  • Lernumgebung in der Cloud
  • 1 Teilnehmender = Fokus aufs Fachliche und maximaler Raum für individuelle Fragen.
Präsenz Online Hybrid
Unverbindlich anfragen

Beschreibung

Eine API ist ein Vertrag - und ein schlechter Vertrag verursacht jahrelang Probleme. Während die meisten API-Kurse zeigen, wie man APIs in Spring Boot, Django oder Express implementiert , beantwortet dieses Seminar die vorgelagerte Frage: Wie entwirft man eine API, die Entwickler gerne nutzen?
Gutes API-Design ist kein Zufall: Es folgt klaren Prinzipien für Ressourcen-Modellierung , URL-Struktur , HTTP-Methoden-Semantik , Fehlerbehandlung und Versionierung . Schlechtes API-Design hingegen - inkonsistente Benennung, fehlende Pagination, kryptische Fehlermeldungen, Breaking Changes ohne Vorwarnung - kostet Unternehmen Hunderttausende Euro an Integrationsaufwand und Entwicklerfrustration.
In diesem Seminar erarbeiten wir die Design-Prinzipien anhand realer API-Beispiele (Stripe, GitHub, Twilio), analysieren Anti-Patterns aus der Praxis, entwerfen Error-Response-Formate nach RFC 9457 und entwickeln ein API Style Guide , das konsistente APIs im gesamten Unternehmen sicherstellt. Jedes Prinzip wird sofort in einer Design-Übung angewandt - nicht in Code, sondern in API-Entwürfen, die anschließend im Peer-Review diskutiert werden.
Unternehmen profitieren von APIs, die weniger Support-Anfragen erzeugen, schneller integriert werden und langfristig stabil bleiben - weil sie von Anfang an richtig entworfen wurden.
Dieses Seminar vermittelt die Design-Methodik für REST-APIs - sprachunabhängig und framework-unabhängig. Wer anschließend APIs formal spezifizieren möchte, findet bei der GFU „OpenAPI Specification: APIs design-first definieren, dokumentieren und generieren" (S6748) und „Einführung in TypeSpec" (S5278). Wer APIs in einer konkreten Sprache implementieren möchte, findet „RESTful Web Services mit Java (JAX-RS)", „REST-APIs mit Django REST Framework" oder „Python-Framework FastAPI". Wer APIs testen möchte, findet „API Tests mit Postman" (S3042).

Schulungsziel

Die Teilnehmenden erlernen die systematische Gestaltung von REST-APIs, die intuitiv verständlich, konsistent und langlebig sind. Ziel ist die Fähigkeit, Ressourcen sauber zu modellieren, HTTP-Methoden und Status Codes korrekt einzusetzen, eine durchdachte Versionierungs- und Fehlerbehandlungsstrategie zu wählen und ein API Style Guide für das eigene Team zu definieren. Am Ende des Seminars können die Teilnehmenden ein API-Design-Review durchführen und die häufigsten Design-Fehler identifizieren und korrigieren.

Details

Inhalt

Tag 1: Ressourcen, HTTP-Semantik und Konsistenz
  • Ziele und Erwartungen der Teilnehmenden
    • Klärung individueller Lernziele und Erwartungen für ein praxisnahes und relevantes Seminar
  • 1. Was gutes API-Design ausmacht - und was schlechtes kostet
    • API als Produkt: Eine API ist eine Benutzungsoberfläche für Entwickler - Developer Experience (DX) entscheidet über Adoption und Erfolg.
    • Die wahren Kosten schlechter APIs: Inkonsistente Benennung -> Dokumentation wird zur Pflichtlektüre. Fehlende Pagination -> Clients brechen bei großen Datenmengen. Breaking Changes -> alle Konsumenten müssen gleichzeitig anpassen. Kryptische Fehler -> Support-Tickets statt Selbsthilfe.
    • Prinzip der geringsten Überraschung: Eine API sollte sich so verhalten, wie ein Entwickler es intuitiv erwartet - ohne die Dokumentation lesen zu müssen.
    • Vorbilder analysieren: Was macht die Stripe-API, die GitHub-API und die Twilio-API so gut? Gemeinsame Muster identifizieren.
  • 2. Ressourcen-Modellierung: Das Fundament jeder REST-API
    • Ressourcen denken, nicht Aktionen: REST modelliert Dinge (Nomen), nicht Vorgänge (Verben). /users statt /getUsers, /orders statt /createOrder.
    • Collection vs. Item: /users (alle Benutzer) vs. /users/42 (ein bestimmter Benutzer). Pluralform für Collections ist Konvention.
    • Hierarchie und Beziehungen: /users/42/orders (Bestellungen eines Benutzers), /orders/99/items (Positionen einer Bestellung). Wann verschachteln, wann flach halten? Faustregel: maximal 2 Ebenen tief.
    • Sub-Ressourcen vs. eigenständige Ressourcen: /users/42/addresses vs. /addresses?user_id=42 - wann welcher Ansatz? Ownership vs. Referenz.
    • Singleton-Ressourcen: /users/42/profile (genau ein Profil pro Benutzer, kein Array).
    • Design-Übung: Teilnehmende modellieren die Ressourcen für ein E-Commerce-System (Kunden, Bestellungen, Produkte, Bewertungen, Warenkorb) - URL-Struktur auf Papier, Peer-Review.
  • 3. HTTP-Methoden: Die richtige Semantik für jede Operation
    • GET: Lesen, niemals Seiteneffekte. Idempotent und cacheable. GET /users/42 liefert immer denselben Benutzer.
    • POST: Erstellen einer neuen Ressource. Nicht idempotent (zweimal senden = zwei Ressourcen). POST /users erstellt einen neuen Benutzer, Response: 201 Created + Location-Header.
    • PUT: Vollständiges Ersetzen einer Ressource. Idempotent (zweimal senden = selbes Ergebnis). PUT /users/42 ersetzt den gesamten Benutzer.
    • PATCH: Teilweises Aktualisieren. PATCH /users/42 mit {"email": "neu@example.com"} ändert nur die E-Mail. JSON Merge Patch (RFC 7396) vs. JSON Patch (RFC 6902).
    • DELETE: Löschen. Idempotent. DELETE /users/42. Was zurückgeben? 204 No Content (Standard) oder 200 mit der gelöschten Ressource (für Undo-Szenarien).
    • Idempotenz-Tabelle: GET ✓, PUT ✓, DELETE ✓, POST ✗, PATCH ✗ (aber oft idempotent implementiert). Warum Idempotenz für Retry-Logik kritisch ist.
    • Wann POST statt PUT? Client kennt die ID nicht -> POST. Client kennt die ID -> PUT. Upsert-Pattern: PUT erstellt oder aktualisiert.
    • Anti-Pattern: POST /users/delete/42, GET /users/create?name=Anna - Verben in URLs, GET mit Seiteneffekten.
  • 4. HTTP-Status Codes: Die richtige Antwort auf jede Situation
    • 2xx Erfolg: 200 OK (Standardantwort), 201 Created (nach POST, mit Location-Header), 202 Accepted (asynchrone Verarbeitung gestartet), 204 No Content (nach DELETE oder PUT ohne Response-Body).
    • 3xx Umleitung: 301 Moved Permanently (API-Endpunkt umgezogen), 304 Not Modified (Caching mit ETag/If-None-Match).
    • 4xx Client-Fehler: 400 Bad Request (ungültiger Body/Parameter), 401 Unauthorized (nicht authentifiziert), 403 Forbidden (authentifiziert, aber nicht berechtigt), 404 Not Found (Ressource existiert nicht), 405 Method Not Allowed (PUT auf read-only), 409 Conflict (Duplikat, Versionkonflikt), 422 Unprocessable Entity (syntaktisch korrekt, semantisch falsch), 429 Too Many Requests (Rate Limit erreicht).
    • 5xx Server-Fehler: 500 Internal Server Error (unerwarteter Fehler), 502 Bad Gateway (Upstream-Service nicht erreichbar), 503 Service Unavailable (Wartung, Überlast), 504 Gateway Timeout.
    • Die häufigsten Fehler: 200 für alles (auch Fehler), 500 bei Validierungsfehlern, 404 vs. 403 Verwechslung (Security: 404 statt 403 zurückgeben, um Existenz nicht zu verraten).
    • Design-Übung: 10 API-Szenarien bewerten - welcher Status Code ist korrekt? Diskussion der Grenzfälle.
  • 5. Naming Conventions: Konsistenz als Qualitätsmerkmal
    • URL-Pfade: kebab-case für URLs (/user-groups statt /userGroups oder /user_groups). Plural für Collections (/users, /orders, /invoices). Keine Dateiendungen (.json, .xml) - Content Negotiation über Accept-Header.
    • Query-Parameter: snake_case oder camelCase - eines wählen und durchziehen. Konsistenz schlägt Konvention.
    • JSON-Properties: camelCase ist Industriestandard (JavaScript-Herkunft). {"firstName": "Anna", "lastName": "Müller", "createdAt": "2026-04-10T14:30:00Z"}.
    • Datumsformate: ISO 8601 immer und überall (2026-04-10T14:30:00Z). Keine Unix-Timestamps, keine lokalen Formate.
    • Booleans: is_active, has_children, can_edit - Präfix signalisiert den Typ.
    • Enums: Großbuchstaben mit Unterstrich (PENDING, IN_PROGRESS, COMPLETED) oder kebab-case (pending, in-progress, completed) - eines wählen.
    • Checkliste: 12 Naming-Regeln, die in einem API Style Guide stehen sollten.
Tag 2: Fehlerbehandlung, Pagination, Versionierung und Style Guide
  • 6. Error Handling: Fehler, die Entwickler verstehen
    • Problem Details (RFC 9457): Der Standard für API-Fehlermeldungen. Felder: type (URI zur Fehlerbeschreibung), title (menschenlesbare Zusammenfassung), status (HTTP-Status), detail (spezifische Erklärung), instance (URI der fehlerhaften Anfrage).
    • Validierungsfehler strukturiert zurückgeben: Nicht nur „Bad Request", sondern welches Feld, welche Regel, welcher Wert: {"errors": [{"field": "email", "message": "Ungültige E-Mail-Adresse", "value": "nicht-eine-email"}]}.
    • Error Codes: Maschinenlesbare Fehlercodes zusätzlich zu menschenlesbaren Nachrichten: "code": "INSUFFICIENT_FUNDS" statt nur "message": "Zahlung fehlgeschlagen".
    • Konsistentes Format: Jeder Fehler - egal ob 400 oder 500 - hat dieselbe Struktur. Clients können eine einzige Error-Handling-Logik implementieren.
    • Anti-Pattern: Fehlermeldungen, die Stack Traces enthalten (Sicherheitsrisiko), generische Fehlermeldungen ohne Kontext, unterschiedliche Fehlerformate pro Endpunkt.
    • Design-Übung: Ein Error-Response-Format für die eigene API definieren - basierend auf RFC 9457, angepasst an die eigenen Anforderungen.
  • 7. Pagination, Filtering, Sorting und Suche
    • Warum Pagination Pflicht ist: Ohne Pagination liefert GET /users bei 100.000 Benutzern 100.000 Datensätze. Clients brechen ab, Server werden überlastet, Netzwerk verstopft.
    • Offset-basiert: ?offset=20&limit=10 (einfach, aber Performance-Problem bei großen Offsets: Datenbank muss 10.020 Zeilen lesen, um die letzten 10 zu liefern).
    • Cursor-basiert: ?cursor=eyJpZCI6NDJ9&limit=10 (performanter, kein „Seite 5 von 17"-Problem, aber keine Sprünge möglich). Standard bei großen Datenmengen (Twitter, Slack, Stripe nutzen Cursor).
    • Response-Metadaten: {"data": [...], "pagination": {"total": 1547, "limit": 10, "offset": 20, "next": "/users?offset=30&limit=10"}}.
    • Filtering: ?status=active&created_after=2026-01-01&role=admin. Konsistente Syntax: Feldname=Wert. Für komplexere Filter: ?filter[status]=active&filter[role]=admin (JSON:API-Stil).
    • Sorting: ?sort=created_at (aufsteigend), ?sort=-created_at (absteigend, Minus-Präfix), ?sort=last_name,-created_at (mehrstufig).
    • Suche: ?search=müller (Volltextsuche über relevante Felder) vs. Filtering (exakte Feldwerte).
    • Partial Responses (Sparse Fieldsets): ?fields=id,name,email - nur die benötigten Felder zurückgeben. Reduziert Payload und Verarbeitungsaufwand.
    • Design-Übung: Pagination, Filtering und Sorting für eine Produkt-API entwerfen - URL-Schema definieren, Response-Format festlegen.
  • 8. Versionierung: APIs ändern, ohne Clients zu brechen
    • Breaking vs. Non-Breaking Changes: Breaking: Feld entfernen, Typ ändern, Pflichtfeld hinzufügen, Verhalten ändern. Non-Breaking: Feld hinzufügen, optionalen Parameter ergänzen, neuen Endpunkt einführen.
    • URL-basiert: /v1/users, /v2/users - einfach, sichtbar, aber URL „gehört" zur Ressource, nicht zur Version. Industriestandard (Google, Stripe, Twilio nutzen URL-Versionierung).
    • Header-basiert: Accept: application/vnd.myapi.v2+json oder API-Version: 2 - sauberer (URL bleibt stabil), aber schwerer zu testen und zu dokumentieren.
    • Query-Parameter: /users?version=2 - selten, vermischt Daten- und Meta-Parameter.
    • Empfehlung: URL-basiert für öffentliche APIs (einfachste DX), Header-basiert für interne APIs (mehr Kontrolle).
    • Deprecation-Strategie: Sunset-Header (RFC 8594): Sunset: Sat, 01 Jan 2028 00:00:00 GMT - signalisiert dem Client, wann die Version abgeschaltet wird. Deprecation-Timeline: Ankündigung -> Grace Period (6-12 Monate) -> Abschaltung. Migration Guides bereitstellen.
    • Kompatibilitäts-Tests: Wie stellt man automatisiert sicher, dass ein neues Release keine Breaking Changes enthält? OpenAPI-Diff-Tools, Contract Testing.
  • 9. Bulk Operations, Idempotenz und asynchrone Verarbeitung
    • Bulk Create/Update/Delete: POST /users/bulk mit Array im Body - weniger HTTP-Roundtrips, atomare Verarbeitung. Response: 207 Multi-Status (pro Element Erfolg/Fehler melden).
    • Idempotency Keys: Header Idempotency-Key: abc123 - Client sendet bei Retry denselben Key, Server erkennt Duplikat und liefert das Ergebnis der ersten Anfrage. Kritisch für Zahlungen und Bestellungen (Stripe-Pattern).
    • Asynchrone Verarbeitung: Langläufer (Report-Generierung, Datenimport) sofort mit 202 Accepted quittieren, Statusabfrage über GET /jobs/42 ermöglichen. Status: pending -> processing -> completed/failed. Webhook als Alternative: Server benachrichtigt Client bei Fertigstellung.
    • Conditional Requests: ETag + If-None-Match (Caching), If-Match (Optimistic Locking: „Ändere nur, wenn sich nichts geändert hat seit meinem letzten GET").
  • 10. HATEOAS und Hypermedia: Selbstbeschreibende APIs
    • Was ist HATEOAS? Hypermedia as the Engine of Application State - die API sagt dem Client, welche Aktionen als Nächstes möglich sind, statt dass der Client URLs hardcodiert.
    • Link-Objekte: {"data": {"id": 42, "status": "draft"}, "links": {"self": "/orders/42", "submit": "/orders/42/submit", "delete": "/orders/42"}} - der Client weiß: diese Bestellung kann eingereicht oder gelöscht werden.
    • Richardson Maturity Model: Level 0 (ein Endpunkt, POST für alles), Level 1 (Ressourcen), Level 2 (HTTP-Methoden), Level 3 (Hypermedia/HATEOAS). Die meisten APIs sind Level 2 - Level 3 wird selten vollständig umgesetzt.
    • Pragmatischer Einsatz: Pagination-Links (next, prev, first, last) und Aktion-Links (submit, cancel, approve) sind praktischer HATEOAS-Einsatz, ohne die volle Komplexität.
    • Wann HATEOAS lohnt: Workflows mit zustandsabhängigen Aktionen (Bestellprozess, Genehmigungsverfahren). Wann nicht: einfache CRUD-APIs, bei denen der Client die URL-Struktur ohnehin kennt.
  • 11. API Style Guide: Konsistenz im Team und in der Organisation
    • Warum ein Style Guide? 10 Entwickler, 10 API-Designs - ohne Guide hat jeder Microservice andere Konventionen. Ein Style Guide macht APIs vorhersagbar.
    • Inhalte eines API Style Guide: URL-Konventionen, Naming, Pagination-Format, Error-Response-Format, Versionierungsstrategie, Authentifizierungsmethode, Rate-Limiting-Verhalten, Datumsformate.
    • Vorbilder: Analyse der API Style Guides von Zalando, Adidas, Microsoft und Google - was können wir übernehmen?
    • Automatisierte Durchsetzung: Spectral (OpenAPI-Linting-Tool - Brücke zu S6748 OpenAPI Spec): Style-Guide-Regeln als maschinenlesbare Linting-Rules, die in der CI/CD-Pipeline bei jedem Commit geprüft werden.
    • API-Design-Review-Prozess: Wann wird eine API reviewed? Wer reviewed? Checkliste für das Review.
    • Praxis-Workshop: Teilnehmende erstellen einen API Style Guide für ihr Unternehmen - 10 Regeln, die ab morgen gelten. Peer-Review in Kleingruppen.
  • 12. Praxis-Workshop: „The API Design Review"
    • Phase 1 - Design-Challenge (45 Min): Teilnehmende entwerfen in Kleingruppen eine vollständige API für ein vorgegebenes Szenario (z.B. Projekt-Management-Tool oder Buchungssystem): Ressourcen, URLs, HTTP-Methoden, Pagination, Error Handling, Versionierung.
    • Phase 2 - Peer Review (30 Min): Gruppen tauschen ihre API-Entwürfe und führen ein strukturiertes Design-Review durch - anhand der Checkliste aus Topic 11. Feedback: Was ist gut? Was ist inkonsistent? Was würde in Produktion Probleme machen?
    • Phase 3 - Anti-Pattern-Analyse (30 Min): Der Trainer zeigt 5 reale API-Designs mit typischen Fehlern (inkonsistente Benennung, fehlende Pagination, GET mit Seiteneffekten, 200 für Fehler, Breaking Changes ohne Versionierung). Teilnehmende identifizieren die Probleme und schlagen Korrekturen vor.
    • Phase 4 - API Style Guide Finalisierung (15 Min): Jede teilnehmende Person finalisiert ihren API Style Guide (Topic 11) mit den Erkenntnissen aus Review und Anti-Pattern-Analyse.
    • Ergebnis: Jede teilnehmende Person verlässt das Seminar mit einem API-Entwurf (peer-reviewed), einem API Style Guide (10+ Regeln) und einer Design-Review-Checkliste für den Arbeitsalltag.

  • Backend-Entwickler: Die REST-APIs für Web- und Mobile-Anwendungen entwerfen und implementieren.
  • Software-Architekten: Die API-Guidelines für Teams und Organisationen definieren.
  • Frontend-Entwickler: Die REST-APIs konsumieren und verstehen möchten, wie gute APIs ihr Leben einfacher machen.
  • Product Owner und technische Projektleiter: Die API-Design-Reviews durchführen oder API-Produkte verantworten.
Voraussetzungen: Grundkenntnisse in HTTP (Methoden, Status Codes, Header) und JSON. Erfahrung mit mindestens einer Programmiersprache. Keine Vorkenntnisse in API-Design-Theorie erforderlich.


In Präsenz
Online
Lernmethode

Ausgewogene Mischung aus Theorie und praktischen Übungen auf persönlichem Schulungs-PC.

Wie auch bei unseren Präsenz-Seminaren: Ausgewogene Mischung aus Theorie und praktischen Übungen. Trainer durchgehend präsent.

Unterlagen

Seminarunterlagen oder Fachbuch inklusive. Das Fachbuch wählt der Trainer passend zum Seminar aus - Ihren individuellen Buch-Wunsch berücksichtigen wir auf Nachfrage gerne.

Seminarunterlagen oder Fachbuch inklusive (via DHL). Das Fachbuch wählt der Trainer passend zum Seminar aus - Ihren individuellen Buch-Wunsch berücksichtigen wir auf Nachfrage gerne.

Arbeitsmaterialien

Din A4 Block, Notizblock, Kugelschreiber, USB-Stick, Textmarker, Post-its

Teilnahmezertifikat

Nach Abschluss des Seminars erhalten Sie das Teilnahmezertifikat inkl. Inhaltsverzeichnis per E-Mail als PDF.


In Präsenz
Online
Teilnehmendenzahl

min. 1, max. 8 Personen

Garantierte Durchführung *

Ab 1 Teilnehmenden

Schulungszeiten
2 Tage, 09:00 - 16:00 Uhr
Ort der Schulung
GFU Schulungszentrum oder Virtual Classroom
GFU Schulungszentrum
Am Grauen Stein 27
51105 Köln-Deutz

oder online im Virtual Classroom oder europaweit bei Ihnen als Inhouse-Schulung

Um ein optimales Raumklima zu gewährleisten, haben wir das Schulungszentrum mit 17 hochmodernen Trotec TAC V+ Luftreinigern ausgestattet. Diese innovative Filtertechnologie (H14 zertifiziert nach DIN EN1822) sorgt dafür, dass die Raumluft mehrfach pro Stunde umgewälzt wird und Schadstoffe zu 99.995% im HEPA-Filter abgeschieden und infektiöse Aerosole abgetötet werden.

Zusätzlich sind alle Räume mit CO2-Ampeln ausgestattet, um jederzeit eine hervorragende Luftqualität sicherzustellen.

Räumlichkeiten

Helle und modern ausgestattete Räume mit perfekter Infrastruktur

Bequem aus dem Homeoffice von überall

All-Inclusive

Frühstück, Snacks und Getränke ganztägig, Mittagessen im eigenen Restaurant, täglich 6 Menüs, auch vegetarisch

Eine Auswahl unserer Frühstücks-Snacks und Nervennahrungs-Highlights senden wir Ihnen mit den Seminarunterlagen via DHL zu.
Barrierefreiheit

Das GFU-Schulungszentrum (Am Grauen Stein 27) ist barrierefrei

-

In Präsenz
Online
  • Eigener Shuttle-Service
  • Reservierte Parkplätze
  • Hotelreservierung
  • Technik-Sofort-Support

Buchungsmöglichkeiten

Online oder in Präsenz teilnehmen

Sie können sowohl Online als auch in Präsenz am Seminar teilnehmen. Klicken Sie bei Ihrer Buchung oder Anfrage einfach die entsprechende Option an.

Mehr Infos
Inhouse-/Firmenschulung
  • Lernumgebung in der Cloud
  • Inhalte werden auf Wunsch an die Anforderungen Ihres Teams angepasst.
Präsenz Online Hybrid
Unverbindlich anfragen
Individualschulung
  • Lernumgebung in der Cloud
  • 1 Teilnehmender = Fokus aufs Fachliche und maximaler Raum für individuelle Fragen.
Präsenz Online Hybrid
Unverbindlich anfragen

So haben GFU-Kunden gestimmt

Zu diesem Seminar wurden noch keine Bewertungen abgegeben.

FAQ für Inhouse Schulungen

Bei einer offenen Schulung stehen Ort und Termin vorab fest. Jeder Interessent kann eine offene Schulung buchen, daher treffen Teilnehmer aus verschiedenen Unternehmen aufeinander.

Inhouse Schulungen können auf Ihren individuellen Schulungsbedarf zugeschnitten werden. Sie bestimmen den Teilnehmerkreis, Termin und Schulungsort.

Bei einer Inhouse Schulung gehen wir auf die individuellen Bedürfnisse Ihres Unternehmens ein und decken den Schulungsbedarf direkt bei Ihnen im Unternehmen ab.

Das spart Zeit und Geld und sorgt für einen schnellen Wissenstransfer Ihrer Mitarbeiter.

Eine komplette Lernumgebung in der Cloud mit Remote Zugriff ist für uns selbstverständlich. Sie müssen sich um nichts kümmern. Lediglich ein funktionierender PC oder Notebook mit Internetanschluss sollte für jeden Teilnehmer am Schulungstag bereit stehen.

  • Kompetente Seminarberatung
  • Dozenten aus der Praxis
  • Auf Ihre Bedürfnisse zugeschnittener individueller Lernstoff
  • Sie können den Termin flexibel gestalten, so wie es für Sie am besten passt
  • Unsere Inhouse Schulungen können Europaweit durchgeführt werden
  • Der Fokus liegt auf Ihrem Schulungsbedarf, somit schonen Sie Ihr Budget
  • Wissenslücken Ihrer Mitarbeitet werden schnell geschlossen
aegallianzaxaElement 1deutsche-bankdeutsche-postlufthansamercedessonyzdf
159.159
Teilnehmende
4.768
Seminarthemen
38.875
Durchgeführte Seminare