Génération REST

L'API REST est du glue code.
Pas besoin de l'écrire.

HexaGlue génère les controllers Spring MVC, DTOs avec validation et documentation OpenAPI depuis vos ports driving. Zéro code manuel pour la couche API REST.

Installer et configurer le plugin Dépendance Maven, goals, paramètres et options.
Documentation
Artefacts générés

5 types d'artefacts, dérivés de vos ports driving

À partir de chaque port driving (interface de cas d'utilisation), HexaGlue produit toute la couche API REST. Pour un domaine e-commerce avec 3 ports driving, cela représente 3 controllers, 6+ DTOs, un handler d'exceptions et une configuration Spring.
ArtefactQuantité typiqueRôle
Controller1 par port driving@RestController avec @RequestMapping, @Tag OpenAPI et injection du port
Request DTO1 par méthode avec bodyRecord Java avec annotations @NotNull, @NotBlank, @Positive de Bean Validation
Response DTO1 par type de retourRecord Java avec factory from() pour la projection domaine vers REST
Exception Handler1 global@RestControllerAdvice avec mappings exception vers code HTTP configurables
Configuration1 global@Configuration avec @Bean exposant les services via leurs ports driving

Le nombre d'artefacts croît linéairement avec le nombre de ports driving. Pour chaque interface de cas d'utilisation ajoutée au domaine, HexaGlue produit un controller complet avec ses DTOs. C'est du code que vous n'avez pas à écrire ni à maintenir.

Dérivation HTTP

Des noms de méthode aux verbes HTTP

HexaGlue analyse chaque méthode du port driving et dérive automatiquement le verbe HTTP, le chemin et le code de statut. Cette dérivation est déterministe : un même port produit toujours la même API.
Préfixe de méthodeVerbeCheminStatut
create, add, registerPOST/201
get, find, loadGET/{id}200
list, getAll, findAllGET/200
update, modify, editPUT/{id}200
delete, remove, archiveDELETE/{id}204
search, queryGET/search200

Ces règles sont déterministes : pour un même port driving, HexaGlue produit toujours la même API REST. Les identifiants de type wrapper (comme OrderId(UUID)) sont automatiquement dépliés vers leur type primitif dans les @PathVariable et reconstruits via la factory OrderId.of(uuid).

Comparaison

Votre port vs le code généré

Vous définissez le contrat métier via un port driving. HexaGlue génère le controller REST, les DTOs et la validation. Les deux sont synchronisés par construction.
Ce que vous écrivez : port driving
// Votre port driving : un contrat métier, pas une API HTTP
public interface OrderUseCases {
Order createOrder(CustomerId customerId, List<OrderLine> lines);
Order getOrder(OrderId id);
List<Order> listOrders();
void deleteOrder(OrderId id);
Order updateOrder(OrderId id, List<OrderLine> lines);
}
Ce que HexaGlue génère : controller REST
@RestController
@RequestMapping("/api/orders")
@Tag(name = "Orders", description = "Order management operations")
public class OrderController {
private final OrderUseCases orderUseCases;
public OrderController(OrderUseCases orderUseCases) {
this.orderUseCases = orderUseCases;
}
@PostMapping
@Operation(summary = "Create order")
public ResponseEntity<Object> createOrder(
@Valid @RequestBody CreateOrderRequest request) {
var result = orderUseCases.createOrder(
CustomerId.of(request.customerId()), request.lines());
return ResponseEntity.status(201).body(OrderResponse.from(result));
}
@GetMapping("/{id}")
@Operation(summary = "Get order")
public ResponseEntity<Object> getOrder(@PathVariable UUID id) {
var result = orderUseCases.getOrder(OrderId.of(id));
return ResponseEntity.ok(OrderResponse.from(result));
}
@GetMapping
@Operation(summary = "List orders")
public ResponseEntity<Object> listOrders() {
var result = orderUseCases.listOrders();
return ResponseEntity.ok(result.stream()
.map(OrderResponse::from).toList());
}
@DeleteMapping("/{id}")
@Operation(summary = "Delete order")
public ResponseEntity<Void> deleteOrder(@PathVariable UUID id) {
orderUseCases.deleteOrder(OrderId.of(id));
return ResponseEntity.noContent().build();
}
}
Ce que HexaGlue génère : DTOs avec validation
// Request DTO : validation automatique depuis les types du domaine
public record CreateOrderRequest(
@NotNull UUID customerId,
@Valid @NotEmpty List<OrderLineRequest> lines
) {}
// Response DTO : factory from() pour la projection domaine → REST
public record OrderResponse(
UUID id,
UUID customerId,
String status
) {
public static OrderResponse from(Order source) {
return new OrderResponse(
source.getId().value(),
source.getCustomerId().value(),
source.getStatus().name());
}
}

Chaque méthode du port driving produit un endpoint REST complet : annotation HTTP, validation des entrées, projection de la réponse et documentation OpenAPI. Ajoutez une méthode au port, le controller se met à jour au prochain build.

Ownership

Du code généré qui vous appartient

Le code produit par HexaGlue n'est pas une boîte noire. Ce sont des classes Java standard, lisibles, débuggables. Vous choisissez comment les intégrer à votre projet.

Régénérer à chaque build

Mode par défaut. Les artefacts sont écrits dans target/ et régénérés à chaque mvn compile. Le code généré n'est pas versionné : il reste toujours synchronisé avec vos ports driving.

Committer dans votre code

Redirigez la sortie vers src/main/java via l'option outputDirectory. Le code généré devient partie intégrante de votre projet. Vous pouvez ensuite le modifier, l'enrichir ou désactiver la régénération.

Le plugin génère des controllers Spring MVC standards avec des records Java pour les DTOs. Pas de framework propriétaire, pas de runtime : le code généré fonctionne avec n'importe quelle version de Spring Boot compatible.

Besoin d'une génération sur mesure ?

Ce plugin démontre qu'il est possible de générer automatiquement toute la couche API REST depuis les ports driving. Bien qu'il couvre les patterns les plus courants, il ne prétend pas répondre à toutes les conventions et exigences de chaque entreprise.

Votre métier mérite toute votre attention.
Générez l'API REST au build.

Voyez comment HexaGlue produit des controllers REST complets à partir de ports driving.