Jakarta RESTful Web Services 4.0

Apply the Jakarta EE 11 prompt first, including its Java 21 baseline. Jakarta REST 4.0 / API 4.0.0 requires Java SE 17 or later; these rules target Java 21. In standalone deployments, provide and verify the authentication, validation, and managed-execution integrations that an EE container would otherwise supply.

Registration and resource lifecycle

• Define an explicit resource and provider set with Application.getClasses() and review any instances returned by getSingletons(). In Servlet deployments, leaving both collections empty enables discovery throughout the WAR; it does not expose an empty application. Inspect the deployed set, including administrative and documentation resources.
• Audit service-loaded Feature and DynamicFeature implementations as well as @Provider scanning. Service loading is enabled by default even when classes are enumerated. To disable it, return "jakarta.ws.rs.loadServices" -> Boolean.FALSE from Application.getProperties() and explicitly replace any required integrations; verify deployment properties do not override the setting.
• Keep filters, interceptors, converters, and other providers free of mutable per-request state: providers normally serve concurrent requests through one instance. Use parameter injection on resource methods for shared resource instances; @PathParam, @QueryParam, and similar field/property injection is supported only for the default per-request lifecycle. Initialize application-created subresources through ResourceContext.initResource when they require REST injection.
• Set