No description
Find a file
Jérémy Munsch a93fde3a3c
feat(api): implement rate limiting and error handling
- Added rate limiting for web and API requests.
- Introduced custom error handling for "Too Many Requests" response.
- Created view for "Too Many Requests" error documentation.
2026-08-12 17:25:45 +02:00
.intellipest feat(api): implement tracer bullet for employees and OpenAPI specification 2026-08-12 15:45:29 +02:00
bootstrap feat(api): implement rate limiting and error handling 2026-08-12 17:25:45 +02:00
config feat(api): implement rate limiting and error handling 2026-08-12 17:25:45 +02:00
database feat(api): implement tracer bullet for employees and OpenAPI specification 2026-08-12 15:45:29 +02:00
documentation feat(api): add health check endpoint 2026-08-12 17:12:35 +02:00
public feat(api): implement tracer bullet for employees and OpenAPI specification 2026-08-12 15:45:29 +02:00
resources docs(README): update API description and architecture details 2026-08-12 17:00:48 +02:00
routes refactor(api): restructure root response to include versions 2026-08-12 17:11:37 +02:00
src feat(api): implement rate limiting and error handling 2026-08-12 17:25:45 +02:00
storage feat(api): implement tracer bullet for employees and OpenAPI specification 2026-08-12 15:45:29 +02:00
tests test(architecture): add rules to prevent Presenters and Views 2026-08-12 17:01:09 +02:00
.editorconfig feat(api): implement tracer bullet for employees and OpenAPI specification 2026-08-12 15:45:29 +02:00
.env.example feat(api): implement tracer bullet for employees and OpenAPI specification 2026-08-12 15:45:29 +02:00
.env.testing feat(api): implement tracer bullet for employees and OpenAPI specification 2026-08-12 15:45:29 +02:00
.gitattributes feat(api): implement tracer bullet for employees and OpenAPI specification 2026-08-12 15:45:29 +02:00
.gitignore feat(api): implement tracer bullet for employees and OpenAPI specification 2026-08-12 15:45:29 +02:00
.gitlab-ci.yml ci: add and configure GitLab CI pipeline 2026-08-12 15:45:30 +02:00
artisan feat(api): implement tracer bullet for employees and OpenAPI specification 2026-08-12 15:45:29 +02:00
composer.json chore(dependencies): update dependencies and add phpstan extension 2026-08-12 16:40:32 +02:00
composer.lock chore(dependencies): update dependencies and add phpstan extension 2026-08-12 16:40:32 +02:00
phpcs.xml feat(api): implement tracer bullet for employees and OpenAPI specification 2026-08-12 15:45:29 +02:00
phpstan.neon chore(dependencies): update dependencies and add phpstan extension 2026-08-12 16:40:32 +02:00
phpunit.xml feat(api): implement tracer bullet for employees and OpenAPI specification 2026-08-12 15:45:29 +02:00
pint.json feat(api): implement tracer bullet for employees and OpenAPI specification 2026-08-12 15:45:29 +02:00
README.md docs(README): update API description and architecture details 2026-08-12 17:00:48 +02:00
rector.php feat(api): implement tracer bullet for employees and OpenAPI specification 2026-08-12 15:45:29 +02:00

Arcadia API

Arcadia API est une application construite en respectant les principes de la Clean Architecture et du Domain-Driven Design (DDD).

Architecture

Arcadia API Architecture

L'application est découpée en couches strictes respectant la règle de dépendance vers l'intérieur :

  1. Domain : Le coeur métier de l'application utilisant un language commun. Ne dépend de rien d'autre (Shared autorisé). Contient les Entités, Value Objects, et les interfaces (Ports) pour interagir avec le monde extérieur.
  2. Application : Les Use Cases. Orchestre la logique métier en utilisant le Domaine. Ne dépend d'aucune infrastructure ou framework (sauf Shared).
  3. Presentation : Les points d'entrée de l'application (API Controllers, Presenters). Formate les données pour l'extérieur et gère les requêtes HTTP ou une interface cli.
  4. Infra : L'implémentation technique (Eloquent, base de données, réseau, etc.). Implémente les interfaces définies par le Domaine.
  5. Shared : Le socle technique commun (interfaces DDD de base, Value Objects génériques comme Pagination).

Principes d'implémentation

  • API Read-only : Pour l'instant, l'API ne fait qu'exposer des données. Nous utilisons donc le pattern Directory (lecture seule) plutôt que Repository (lecture/écriture) dans nos Ports de Domaine.
  • Pattern Presenter : Les Use Cases (dans Application) retournent un Output agnostique. La couche Presentation utilise ensuite des Presenters spécifiques (ex: API) pour transformer cet Output en une vue exploitable par l'interface finale (JSON).
  • Validation : La validation stricte du format (ex: HTTP) est gérée dans la couche Presentation (via les FormRequest). La validation des règles métier est garantie au coeur du Domain par les Value Objects, qui lèvent des exceptions de type InvalidArgumentException traduites en HTTP 422 par le gestionnaire d'erreurs global.