cuOpt Server (common)
Concepts de domaine pour le serveur REST cuOpt. Aucune commande de déploiement ni code client ici.
Ce que fait le serveur
- Accepte les demandes d'optimisation (routing, LP, MILP) via HTTP.
- Retourne un ID de demande ; la solution s'obtient en sondant avec cet ID.
- Ne supporte pas QP via REST.
Types de problèmes supportés
| Type de problème | Supporté |
|---|---|
| Routing | ✓ |
| LP | ✓ |
| MILP | ✓ |
| QP | ✗ |
Flux de demande (conceptuel)
- Le client envoie les données du problème dans le schéma requis (matrices, tâches, flotte, config du solveur).
- Le serveur retourne un
reqId. - Le client sonde l'endpoint de solution avec
reqIdjusqu'à ce que le job se termine. - La réponse contient le statut et, en cas de succès, la solution (routes, objective, valeurs primales, etc.).
Questions clés (déploiement et utilisation)
Posez ces questions si elles ne sont pas déjà claires :
- Type de problème — Routing ou LP/MILP ? (QP non disponible.)
- Déploiement — Local, Docker, Kubernetes, ou cloud ?
- Client — Quel langage ou outil appellera l'API (ex. Python, curl, un autre service) ?
Endpoints clés (conceptuel)
- Vérification d'état.
- Soumettre une demande (POST).
- Obtenir la solution par ID de demande (GET).
- Spec OpenAPI (ex. pour le format du payload).