Spezifikation / Framework-APIWeb/API4.0

Jakarta RESTful Web Services

Standardisierte REST APIs mit Ressourcenklassen, Pfaden, HTTP-Methoden, Content Negotiation und Exception Mapping.

Einordnung
Spezifikation / Framework-API
Enterprise-Rolle
REST ist der wichtigste Standardzugang für moderne Jakarta-Enterprise-Systeme.
Diagramm zu Jakarta RESTful Web Services

Fachliches Verständnis

REST ist der wichtigste Standardzugang für moderne Jakarta-Enterprise-Systeme. In der Praxis ist wichtig, die Spezifikation nicht mit der konkreten Runtime zu verwechseln. Der Standard beschreibt die portablen APIs, die Implementierung entscheidet über Konfiguration, Performance, Betrieb und Support.

Kernkonzepte

  • @Path, @GET, @POST, @Produces, @Consumes.
  • Param Binding über @PathParam, @QueryParam und @BeanParam.
  • ExceptionMapper für konsistente Fehler.
  • Filters und Interceptors für API-Querschnitt.

Typische Einsatzfälle

  • REST API vor Fachservices setzen.
  • SOAP oder EJB Remote schrittweise mit HTTP/JSON Fassade ersetzen.

Technisches Beispiel

java
@Path("/orders")
@RequestScoped
@Consumes(MediaType.APPLICATION_JSON)
@Produces(MediaType.APPLICATION_JSON)
public class OrderResource {
    @Inject PlaceOrderUseCase placeOrder;

    @POST
    public Response place(@Valid PlaceOrderRequest request) {
        OrderId id = placeOrder.place(request.toCommand());
        return Response.created(URI.create("/orders/" + id.value()))
                .entity(new OrderResponse(id.value(), "ACCEPTED"))
                .build();
    }
}

@Provider
public class DomainExceptionMapper implements ExceptionMapper<DomainRuleViolation> {
    public Response toResponse(DomainRuleViolation ex) {
        return Response.status(422).entity(Map.of("error", ex.getMessage())).build();
    }
}
Architekturregel: Jakarta APIs gehören an Systemgrenzen und Infrastrukturpunkte. Fachentscheidungen bleiben in Application Services und Domain-Modellen testbar und möglichst unabhängig vom Container.

Enterprise-Fallen

  • Entity direkt veröffentlichen.
  • HTTP-Statuscodes inkonsistent einsetzen.
  • Transaktionsgrenzen im Resource-Code verstecken.

Legacy-Modernisierung

JAX-RS-Ressourcen können als Anti-Corruption Layer vor Legacy-Services dienen.

Vertiefung: Review-Fragen für Senior-Entwickler
  • Welche Spezifikation ist hier wirklich nötig?
  • Welche Runtime-Funktion wird genutzt und ist sie portabel?
  • Wo liegt die Transaktionsgrenze?
  • Sind API-Verträge, DTOs und Domain-Modelle getrennt?
  • Ist der Code ohne Application Server testbar?