## Jakarta RESTful Web Services - 3.1
Specification Assertion Detail

Totals | Total | Active | Deprecated | Removed
# of Assertions | 241 | 239 | 0 | 4
# of Required Assertions | 238 | 236 | 0 | 4
# of Optional Assertions | 3 | 3 | 0 | 0

ID | Chapter | Section | Description | Required | Dependency | Implementation Specific | Defined by | Status | Testable
JAXRS:SPEC:1 | 3 | 1.2 | Root resource classes are instantiated by the RESTful Web Services runtime and MUST have a public constructor for which the RESTful Web Services runtime can provide all parameter values. Note that a zero argument constructor is permissible under this rule. | true |  | false | technology | active | true
JAXRS:SPEC:2 | 3 | 1.2 | If more than one public constructor is suitable then an implementation MUST use the one with the most parameters. | true |  | false | technology | active | true
JAXRS:SPEC:3 | 3 | 2 | When a resource class is instantiated, the values of ﬁelds and bean properties annotated with one the following annotations are set according to the semantics of the annotation: | true |  | false | technology | active | true
JAXRS:SPEC:3.1 | 3 | 2 | @MatrixParam Extracts the value of a URI matrix parameter. | true |  | false | technology | active | true
JAXRS:SPEC:3.2 | 3 | 2 | @QueryParam Extracts the value of a URI query parameter. | true |  | false | technology | active | true
JAXRS:SPEC:3.3 | 3 | 2 | @PathParam Extracts the value of a URI template parameter. | true |  | false | technology | active | true
JAXRS:SPEC:3.4 | 3 | 2 | @CookieParam Extracts the value of a cookie. | true |  | false | technology | active | true
JAXRS:SPEC:3.5 | 3 | 2 | @HeaderParam Extracts the value of a header. | true |  | false | technology | active | true
JAXRS:SPEC:3.6 | 3 | 2 | @Context Injects an instance of a supported resource, | true |  | false | technology | active | true
JAXRS:SPEC:4 | 3 | 2 | An implementation is only required to set the annotated ﬁeld and bean property values of instances created by the implementation runtime. Objects returned by sub-resource locators (see section 3.4.1) are expected to be initialized by their creator and ﬁeld and bean properties are not modiﬁed by the implementation runtime. | true |  | false | technology | active | true
JAXRS:SPEC:5 | 3 | 2 | Valid parameter types for each of the above annotations are listed in the corresponding Javadoc, however in general (excluding @Context) the following types are supported: | true |  | false | technology | active | true
JAXRS:SPEC:5.1 | 3 | 2 | Primitive types. | true |  | false | technology | active | true
JAXRS:SPEC:5.2 | 3 | 2 | Types that have a constructor that accepts a single String argument. | true |  | false | technology | active | true
JAXRS:SPEC:5.3 | 3 | 2 | Types that have a static method named valueOf or fromString with a single String argument. | true |  | false | technology | active | true
JAXRS:SPEC:5.4 | 3 | 2 | List<T>, Set<T>, or SortedSet<T>, where T satisﬁes 2 or 3 above. | true |  | false | technology | active | true
JAXRS:SPEC:5.5 | 3 | 2 | If both methods are present then valueOf MUST be used unless the type is an enum in which case fromString MUST be used. | true |  | false | technology | active | true
JAXRS:SPEC:5.6 | 3 | 2 | Types for which a ParamConverter is available via a registered ParamConverterProvider | true |  | false | technology | active | true
JAXRS:SPEC:6 | 3 | 2 | The DefaultValue annotation may be used to supply a default value for some of the above, see the Javadoc for DefaultValue for usage details and rules for generating a value in the absence of this annotation and the requested data. | true |  | false | technology | active | true
JAXRS:SPEC:7 | 3 | 2 | The Encoded annotation may be used to disable automatic URI decoding for @MatrixParam, @QueryParam, and @PathParam annotated ﬁelds and properties. | true |  | false | technology | active | true
JAXRS:SPEC:8 | 3 | 2 | A WebApplicationException thrown during construction of ﬁeld or property values using 3 or 4 above is processed directly as described in section 3.3.4. | true |  | false | technology | active | true
JAXRS:SPEC:9 | 3 | 2 | Other exceptions thrown during construction of ﬁeld or property values using 3 or 4 above are treated as client errors: | true |  | false | technology | active | true
JAXRS:SPEC:9.1 | 3 | 2 | if the ﬁeld or property is annotated with @MatrixParam, @QueryParam or @PathParam then an implementation MUST generate a WebApplicationException that wraps the thrown exception with a not found response (404 status) and no entity; | true |  | false | technology | active | true
JAXRS:SPEC:9.2 | 3 | 2 | if the ﬁeld or property is annotated with @HeaderParam or @CookieParam then an implementation MUST generate a WebApplicationException that wraps the thrown exception with a client error response (400 status) and no entity. | true |  | false | technology | active | true
JAXRS:SPEC:10 | 3 | 2 | Exceptions MUST be processed as described in section 3.3.4. | true |  | false | technology | active | true
JAXRS:SPEC:11 | 3 | 3.1 | Only public methods may be exposed as resource methods. | true |  | false | technology | active | true
JAXRS:SPEC:12 | 3 | 3.2 | When a resource method is invoked, parameters annotated with @FormParam or one of the annotations listed in section 3.2 are mapped from the request according to the semantics of the annotation. Similar to ﬁelds and bean properties: | true |  | false | technology | active | true
JAXRS:SPEC:12.1 | 3 | 3.2 | The DefaultValue annotation may be used to supply a default value for parameters | true |  | false | technology | active | true
JAXRS:SPEC:12.2 | 3 | 3.2 | The Encoded annotation may be used to disable automatic URI decoding of parameter values | true |  | false | technology | active | true
JAXRS:SPEC:12.3 | 3 | 3.2 | Exceptions thrown during construction of parameter values are treated the same as exceptions thrown during construction of ﬁeld or bean property values, see section 3.2. | true |  | false | technology | active | true
JAXRS:SPEC:13 | 3 | 3.2.1 | Resource methods MUST have at most one entity parameter. | true |  | false | technology | active | false
JAXRS:SPEC:14 | 3 | 3.3 | Resource methods MAY return void, Response, GenericEntity, or another Java type, these return types are mapped to a response entity body as follows: | true |  | false | technology | active | true
JAXRS:SPEC:14.1 | 3 | 3.3 | void: Results in an empty entity body with a 204 status code. | true |  | false | technology | active | true
JAXRS:SPEC:14.2 | 3 | 3.3 | Response: Results in an entity body mapped from the entity property of the Response with the status code speciﬁed by the status property of the Response. | true |  | false | technology | active | true
JAXRS:SPEC:14.3 | 3 | 3.3 | Response: A null return value results in a 204 status code. | true |  | false | technology | active | true
JAXRS:SPEC:14.4 | 3 | 3.3 | Response:If the status property of the Response is not set: a 200 status code is used for a non-null entity property and a 204 status code is used if the entity property is null. | true |  | false | technology | active | true
JAXRS:SPEC:14.5 | 3 | 3.3 | GenericEntity: Results in an entity body mapped from the Entity property of the GenericEntity. If the return value is not null a 200 status code is used | true |  | false | technology | active | true
JAXRS:SPEC:14.6 | 3 | 3.3 | GenericEntity: a null return value results in a 204 status code. | true |  | false | technology | active | true
JAXRS:SPEC:14.7 | 3 | 3.3 | Other: Results in an entity body mapped from the class of the returned instance. If the return value is not null a 200 status code is used | true |  | false | technology | active | true
JAXRS:SPEC:14.8 | 3 | 3.3 | Other: a null return value results in a 204 status code. | true |  | false | technology | active | true
JAXRS:SPEC:15 | 3 | 3.3 | The return type of a resource method and the type of the returned instance are used to determine the raw type and generic type supplied to the isWritable method of MessageBodyWriteras follows: | true |  | false | technology | active | true
JAXRS:SPEC:15.1 | 3 | 3.3 | Return Type | true |  | false | technology | active | true
JAXRS:SPEC:15.2 | 3 | 3.3 | Returned Instance | true |  | false | technology | active | true
JAXRS:SPEC:15.3 | 3 | 3.3 | Raw Type | true |  | false | technology | active | true
JAXRS:SPEC:15.4 | 3 | 3.3 | Generic Type | true |  | false | technology | active | true
JAXRS:SPEC:16 | 3 | 3.4 | A resource method, sub-resource method or sub-resource locator may throw any checked or unchecked exception. An implementation MUST catch all exceptions and process them as follows: | true |  | false | technology | active | true
JAXRS:SPEC:16.1 | 3 | 3.4 | Instances of WebApplicationException MUST be mapped to a response as follows. If the response property of the exception does not contain an entity and an exception mapping provider (see section 4.4) is available for WebApplicationException an implementation MUST use the provider to create a new Response instance, otherwise the response property is used directly. The resulting Response instance is then processed according to section 3.3.3. | true |  | false | technology | active | true
JAXRS:SPEC:16.2 | 3 | 3.4 | If an exception mapping provider (see section 4.4) is available for the exception or one of its superclasses, an implementation MUST use the provider whose generic type is the nearest superclass of the exception to create a Response instance that is then processed according to section 3.3.3. If the exception mapping provider throws an exception while creating a Response then return a server error (status code 500) response to the client. | true |  | false | technology | active | true
JAXRS:SPEC:16.3 | 3 | 3.4 | Unchecked exceptions and errors MUST be re-thrown and allowed to propagate to the underlying container. | true |  | false | technology | removed | true
JAXRS:SPEC:16.4 | 3 | 3.4 | Checked exceptions and throwables that cannot be thrown directly MUST be wrapped in a container-speciﬁc exception that is then thrown and allowed to propagate to the underlying container. Servlet-based implementations MUST use ServletException as the wrapper. JAX-WS Provider-based implementations MUST use WebServiceException as the wrapper. | true |  | false | technology | removed | false
JAXRS:SPEC:17 | 3 | 3.5 | On receipt of a HEAD request an implementation MUST either: | true |  | false | technology | active | true
JAXRS:SPEC:17.1 | 3 | 3.5 | Call a method annotated with a request method designator for HEAD | true |  | false | technology | active | true
JAXRS:SPEC:17.2 | 3 | 3.5 | or, if none present, Call a method annotated with a request method designator for GET and discard any returned entity. | true |  | false | technology | active | true
JAXRS:SPEC:18 | 3 | 3.5 | On receipt of an OPTIONS request an implementation MUST either: | true |  | false | technology | active | true
JAXRS:SPEC:18.1 | 3 | 3.5 | Call a method annotated with a request method designator for OPTIONS or, if none present, | true |  | false | technology | active | true
JAXRS:SPEC:18.2 | 3 | 3.5 | Generate an automatic response from the declared metadata of the matching class. | true |  | false | technology | active | true
JAXRS:SPEC:19 | 3 | 4 | Template parameters can optionally specify the regular expression used to match their values. | false |  | false | technology | active | true
JAXRS:SPEC:20 | 3 | 4.1 | The presence or absence of a request method designator (e.g. @GET) differentiates between the two: | true |  | false | technology | active | true
JAXRS:SPEC:20.1 | 3 | 4.1 | Present Such methods, known as sub-resource methods, are treated like a normal resource method (see section 3.3) except the method is only invoked for request URIs that match a URI template created by concatenating the URI template of the resource class with the URI template of the method | true |  | false | technology | active | true
JAXRS:SPEC:20.2 | 3 | 4.1 | Absent Such methods, known as sub-resource locators, are used to dynamically resolve the object that will handle the request. Any returned object is treated as a resource class instance and used to either handle the request or to further resolve the object that will handle the request, see 3.7 for further details. An implementation MUST dynamically determine the class of object returned rather than relying on the static sub-resource locator return type since the returned instance may be a subclass of the declared type with potentially different annotations, see section 3.6 for rules on annotation inheritance. | true |  | false | technology | active | true
JAXRS:SPEC:20.3 | 3 | 4.1 | Sub-resource locators may have all the same parameters as a normal resource method (see section 3.3) except that they MUST NOT have an entity parameter. | true |  | false | technology | active | true
JAXRS:SPEC:21 | 3 | 5 | An implementation MUST NOT invoke a method whose effective value of @Produces does not match the request Accept header. | true |  | false | technology | active | true
JAXRS:SPEC:22 | 3 | 5 | An implementation MUST NOT invoke a method whose effective value of @Consumes does not match the request Content-Type header. | true |  | false | technology | active | true
JAXRS:SPEC:23 | 3 | 6 | Annotations on a super-class take precedence over those on an implemented interface. | true |  | false | technology | active | true
JAXRS:SPEC:24 | 3 | 6 | If a subclass or implementation method has any RESTful Web Services annotations then all of the annotations on the super class or interface method are ignored. | true |  | false | technology | active | true
JAXRS:SPEC:25 | 3 | 7 | Implementations are not required to use the algorithm as written but MUST produce results equivalent to those produced by the algorithm. | true |  | false | technology | active | true
JAXRS:SPEC:25.1 | 3 | 7.2 | If E is empty then no matching resource can be found, the algorithm terminates and an implementation MUST generate a WebApplicationException with a not found response (HTTP 404 status) and no entity. The exception MUST be processed as described in section 3.3.4. | true |  | false | technology | active | true
JAXRS:SPEC:25.2 | 3 | 7.2 | Sort E using the number of literal characters in each member as the primary key (descending order), the number of capturing groups as a secondary key (descending order) and the number of capturing groups with non-default regular expressions (i.e. not ‘([ˆ/]+?)’) as the tertiary key (descending order). | true |  | false | technology | active | true
JAXRS:SPEC:25.3 | 3 | 7.2 | Sort E using the number of literal characters in each member as the primary key (descending order), the number of capturing groups as a secondary key (descending order), the number of capturing groups with non-default regular expressions (i.e. not ‘([ˆ/]+?)’) as the tertiary key (descending order), and the source of each member as quaternary key sorting those derived from Tmethod ahead of those derived from Tlocator. | true |  | false | technology | active | true
JAXRS:SPEC:25.4 | 3 | 7.2 | The request method is supported. If no methods support the request method an implementation MUST generate a WebApplicationException with a method not allowed response (HTTP 405 status) and no entity. The exception MUST be processed as described in section 3.3.4. Note the additional support for HEAD and OPTIONS described in section 3.3.5. | true |  | false | technology | active | true
JAXRS:SPEC:25.5 | 3 | 7.2 | The media type of the request entity body (if any) is a supported input data format (see section 3.5). If no methods support the media type of the request entity body an implementation MUST generate a WebApplicationException with an unsupported media type response (HTTP 415 status) and no entity. The exception MUST be processed as described in section 3.3.4. | true |  | false | technology | active | true
JAXRS:SPEC:25.6 | 3 | 7.2 | At least one of the acceptable response entity body media types is a supported output data format (see section 3.5). If no methods support one of the acceptable response entity body media types an implementation MUST generate a WebApplicationException with a not acceptable response (HTTP 406 status) and no entity. The exception MUST be processed as described in section 3.3.4. | true |  | false | technology | active | true
JAXRS:SPEC:25.7 | 3 | 7.2 | Let t be the request content type and CM a resource method’s @Consumes set of server media types, we use the media type max>={S(t,c) | (t, c) e {t} X CM} as primary key | true |  | false | technology | active | true
JAXRS:SPEC:25.8 | 3 | 7.2 | Let A be the request accept header set of client media types and PM a resource method’s @Produces set of server media types, we use the media type max>={S(a, p) | (a, p) e A X PM} as secondary key. | true |  | false | technology | active | true
JAXRS:SPEC:25.9 | 3 | 7.2 | n1/m1 > n2/m2 where the partial order > is defined as n/m > n/* > */* | true |  | false | technology | active | true
JAXRS:SPEC:25.10 | 3 | 7.2 | n2/m2 /> n1/m1 and v1 > v2 | true |  | false | technology | active | true
JAXRS:SPEC:25.11 | 3 | 7.2 | n2/m2 /> n1/m1 and v1 = v2 and v1' > v2' | true |  | false | technology | active | true
JAXRS:SPEC:25.12 | 3 | 7.2 | n2/m2 /> n1/m1 and v1 = v2 and v1' = v2' and v1'' <= v2'' | true |  | false | technology | active | true
JAXRS:SPEC:26 | 3 | 8 | The following algorithm is used to determine the response media type, Mselected, at run time | true |  | false | technology | active | true
JAXRS:SPEC:26.1 | 3 | 8 | If the method returns an instance of Response whose metadata includes the response media type (Mspecified) then set Mselected = Mspecified, finish | true |  | false | technology | active | true
JAXRS:SPEC:26.2 | 3 | 8 | If the method is annotated with @Produces, set P = V (method) where V (t) represents the values of @Produces on the specified target t. | true |  | false | technology | active | true
JAXRS:SPEC:26.3 | 3 | 8 | Else if the class is annotated with @Produces, set P = V (class). | true |  | false | technology | active | true
JAXRS:SPEC:26.4 | 3 | 8 | Else set P = V (writers) where ‘writers’ is the set of MessageBodyWriter that support the class of the returned entity object | true |  | false | technology | active | true
JAXRS:SPEC:26.5 | 3 | 8 | If P = , set P = ‘*/*’ | true |  | false | technology | active | false
JAXRS:SPEC:26.6 | 3 | 8 | If A = , set A = ‘*/*’ | true |  | false | technology | active | true
JAXRS:SPEC:26.7 | 3 | 8 | If M = ,then generate a WebApplicationException with a not acceptable response (HTTP 406 status) and no entity. The exception MUST be processed as described in Section 3.3.4. Finish | true |  | false | technology | active | true
JAXRS:SPEC:26.8 | 3 | 8 | Sort M in descending order, with a primary key of specificity (n/m > n/* > */*), a secondary key of q-value and a tertiary key of qs-value. | true |  | false | technology | active | true
JAXRS:SPEC:26.9 | 3 | 8 | If M contains ‘*/*’ or ‘application/*’, set Mselected = ‘application/octet-stream’, finish. | true |  | false | technology | active | false
JAXRS:SPEC:26.10 | 3 | 8 | Generate a WebApplicationException with a not acceptable response (HTTP 406 status) and no entity. The exception MUST be processed as described in section 3.3.4. Finish. | true |  | false | technology | active | true
JAXRS:SPEC:27 | 4 | 1.3 | Provider classes are instantiated by the RESTful Web Services runtime and MUST have a public constructor for which the RESTful Web Services runtime can provide all parameter values. Note that a zero argument constructor is permissible under this rule. | true |  | false | technology | active | true
JAXRS:SPEC:28 | 4 | 1.3 | If more than one public constructor can be used then an implementation MUST use the one with the most parameters. | true |  | false | technology | active | true
JAXRS:SPEC:29 | 4 | 1.3 | In the absence of a suitable entity provider, RESTful Web Services implementations are REQUIRED to use to the JavaBeans Activation Framework[11] to try to obtain a suitable data handler to perform the mapping instead. | true |  | false | technology | removed | false
JAXRS:SPEC:30 | 4 | 2.3 | The absence of these annotations is equivalent to their inclusion with media type (“*/*”), i.e. absence implies that any media type is supported. | true |  | false | technology | active | true
JAXRS:SPEC:31 | 4 | 2.3 | An implementation MUST NOT use an entity provider for a media type that is not supported by that provider. | true |  | false | technology | active | true
JAXRS:SPEC:32 | 4 | 2.3 | When choosing an entity provider an implementation sorts the available providers according to the media types they declare support for. Sorting of media types follows the general rule: x/y < x/* < */*, i.e. a provider that explicitly lists a media types is sorted before a provider that lists */*. | true |  | false | technology | active | true
JAXRS:SPEC:33 | 4 | 2.4 | An implementation MUST include pre-packaged MessageBodyReader and MessageBodyWriter implementations for the following Java and media type combinations: | true |  | false | technology | active | true
JAXRS:SPEC:33.1 | 4 | 2.4 | byte[] All media types (*/*). | true |  | false | technology | active | true
JAXRS:SPEC:33.2 | 4 | 2.4 | java.lang.String All media types (*/*). | true |  | false | technology | active | true
JAXRS:SPEC:33.3 | 4 | 2.4 | java.io.InputStream All media types (*/*). | true |  | false | technology | active | true
JAXRS:SPEC:33.4 | 4 | 2.4 | java.io.Reader All media types (*/*). | true |  | false | technology | active | true
JAXRS:SPEC:33.5 | 4 | 2.4 | java.io.File All media types (*/*). | true |  | false | technology | active | true
JAXRS:SPEC:33.6 | 4 | 2.4 | jakarta.activation.DataSource All media types (*/*). | true |  | false | technology | active | true
JAXRS:SPEC:33.7 | 4 | 2.4 | javax.xml.transform.Source XML types (text/xml, application/xml and application/*+xml). | true |  | false | technology | active | true
JAXRS:SPEC:33.8 | 4 | 2.4 | jakarta.xml.bind.JAXBElement and application-supplied JAXB classes XML media types (text/xml, application/xml and application/*+xml). | true |  | false | technology | active | true
JAXRS:SPEC:33.9 | 4 | 2.4 | MultivaluedMap<String,String> Form content (application/x-www-form-urlencoded). | true |  | false | technology | active | true
JAXRS:SPEC:33.10 | 4 | 2.4 | StreamingOutput All media types (*/*), MessageBodyWriter only. | true |  | false | technology | active | true
JAXRS:SPEC:33.11 | 4 | 2.4 | java.lang.Boolean. Only for text/plain. Corresponding primitive types supported via boxing/unboxing conversion. | true |  | false | technology | active | true
JAXRS:SPEC:33.12 | 4 | 2.4 | java.lang.Character. Only for text/plain. Corresponding primitive types supported via boxing/unboxing conversion. | true |  | false | technology | active | true
JAXRS:SPEC:33.13 | 4 | 2.4 | java.lang.Number. Only for text/plain. Corresponding primitive types supported via boxing/unboxing conversion. | true |  | false | technology | active | true
JAXRS:SPEC:34 | 4 | 2.4 | The implementation-supplied entity provider(s) for jakarta.xml.bind.JAXBElement and application-supplied JAXB classes MUST use JAXBContext instances provided by application-supplied context resolvers, see section 4.3. If an application does not supply a JAXBContext for a particular type, the implementation-supplied entity provider MUST use its own default context instead. | true |  | false | technology | active | true
JAXRS:SPEC:35 | 4 | 2.4 | An implementation MUST support application-provided entity providers and MUST use those in preference to its own pre-packaged providers when either could handle the same request. More precisely, step 4 in Section 4.2.1 and step 5 in Section 4.2.2 MUST prefer application-provided over pre-packaged entity providers. | true |  | false | technology | active | true
JAXRS:SPEC:36 | 4 | 2.5 | MessageBodyReader providers always operate on the decoded HTTP entity body rather than directly on the HTTP message body. | true |  | false | technology | active | false
JAXRS:SPEC:37 | 4 | 2.6 | Content encoding is the responsibility of the application. Application-supplied entity providers MAY perform such encoding and manipulate the HTTP headers accordingly. | false |  | false | technology | active | true
JAXRS:SPEC:38 | 4 | 3.1 | When choosing a context provider an implementation sorts the available providers according to the media types they declare support for. Sorting of media types follows the general rule: x/y < x/* < */*, i.e. a provider that explicitly lists a media type is sorted before a provider that lists */*. | true |  | false | technology | active | true
JAXRS:SPEC:39 | 4 | 4 | When choosing an exception mapping provider to map an exception, an implementation MUST use the provider whose generic type is the nearest superclass of the exception. | true |  | false | technology | active | true
JAXRS:SPEC:40 | 10 | 1 | When injecting an instance of one of the types listed in section 9.2, the instance supplied MUST be capable of selecting the correct context for a particular request. | true |  | false | technology | active | true
JAXRS:SPEC:41 | 10 | 1 | The @Context annotation can be used to indicate a dependency on a Servlet-deﬁned resource. | true |  | false | platform | active | true
JAXRS:SPEC:42 | 11 | 1 | A Servlet-based implementation MUST support injection of the following Servlet-deﬁned types: ServletConfig, ServletContext, HttpServletRequest and HttpServletResponse. | true |  | false | platform | active | true
JAXRS:SPEC:43 | 11 | 1 | An injected HttpServletRequest allows a resource method to stream the contents of a request entity. If the resource method has a parameter whose value is derived from the request entity then the stream will have already been consumed and an attempt to access it MAY result in an exception. . | true |  | false | platform | active | true
JAXRS:SPEC:44 | 11 | 1 | An injected HttpServletResponse allows a resource method to commit the HTTP response prior to returning. An implementation MUST check the committed status and only process the return value if the response is not yet committed. | true |  | false | platform | active | true
JAXRS:SPEC:45 | 11 | 1 | Servlet ﬁlters may trigger consumption of a request body by accessing request parameters. | true |  | false | platform | active | true
JAXRS:SPEC:46 | 11 | 1 | In a servlet container the @FormParam annotation and the standard entity provider for application/x-www-form--urlencoded MUST obtain their values from the servlet request parameters if the request body has already been consumed. | true |  | false | platform | active | true
JAXRS:SPEC:47 | 11 | 1 | Servlet APIs do not differentiate between parameters in the URI and body of a request so URI-based query parameters may be included in the entity parameter. | true |  | false | platform | active | true
JAXRS:SPEC:48 | 11 | 2.1 | In a product that also supports the Servlet speciﬁcation, implementations MUST support RESTful Web Services applications that are packaged as a web application, | true |  | false | platform | active | true
JAXRS:SPEC:49 | 11 | 2.2 | In a product that also supports Managed Beans, implementations MUST support use of Managed Beans as root resource classes, providers and Application subclasses. | true |  | false | platform | active | true
JAXRS:SPEC:50 | 11 | 2.3 | In a product that also supports JSR 299, implementations MUST similarly support use of JSR299-style managed beans. Providers and Application subclasses MUST be singletons or use application scope. | true |  | false | platform | active | true
JAXRS:SPEC:51 | 11 | 2.4 | In a product that also supports EJB, an implementation MUST support use of stateless and singleton session beans as root resource classes, providers and Application subclasses. RESTful Web Services annotations MAY be applied to a bean’s local interface or directly to a no-interface bean. | true |  | false | platform | active | true
JAXRS:SPEC:52 | 11 | 2.4 | If an ExceptionMapper for a EJBException or subclass is not included with an application then exceptions thrown by an EJB resource class or provider method MUST be treated as EJB application exceptions: the embedded cause of the EJBException MUST be unwrapped and processed. | true |  | false | platform | active | true
JAXRS:SPEC:53 | 11 | 2.8 | The following additional requirements apply when using Managed Beans, JSR299-style Managed Beans or EJBs as resource classes, providers or Application subclasses: | true |  | false | platform | active | true
JAXRS:SPEC:53.1 | 11 | 2.8 | Field and property injection of RESTful Web Services resources MUST be performed prior to the container invoking any @PostConstruct annotated method. | true |  | false | platform | active | true
JAXRS:SPEC:53.2 | 11 | 2.8 | Support for constructor injection of RESTful Web Services resources is OPTIONAL. Portable applications MUST instead use ﬁelds or bean properties in conjunction with a @PostConstruct annotated method. Implementations SHOULD warn users about use of non-portable constructor injection. | false |  | false | platform | active | true
JAXRS:SPEC:53.3 | 11 | 2.8 | Implementations MUST NOT require use of @Inject or @Resource to trigger injection of RESTful Web Services annotated ﬁelds or properties. Implementations MAY support such usage but SHOULD warn users about non-portability. | true |  | false | platform | active | true
JAXRS:SPEC:54 | 11 | 3 | Other container technologies MAY specify their own set of injectable resources but MUST, at a minimum, support access to the types of context listed in section 5.2. | true |  | false | platform | active | no
JAXRS:SPEC:55 | 2 | 1 | The resources and providers that make up a RESTful Web Services application are conﬁgured via an application-supplied subclass of Application. An implementation MAY provide alternate mechanisms for locating resource classes and providers (e.g. runtime class scanning) but use of Application is the only portable means of conﬁguration. | true |  | false | technology | active | false
JAXRS:SPEC:56 | 2 | 3.2 | (deploy with Servlet container)If no Application subclass is present the added servlet MUST be named: jakarta.ws.rs.core.Application, and all root resource classes and providers packaged in the web application MUST be included in the published RESTful Web Services application. The application MUST be packaged with a web.xml that speciﬁes a servlet mapping for the added servlet. | true |  | false | platform | active | true
JAXRS:SPEC:57 | 2 | 3.2 | (deploy with Servlet container)If an Application subclass is present and there is already a servlet deﬁned that has a servlet initialization parameter named: jakarta.ws.rs.Application, whose value is the fully qualiﬁed name of the Application subclass then no new servlet should be added by the RESTful Web Services implementation’s ContainerInitializer since the application is already being handled by an existing servlet. | true |  | false | platform | active | true
JAXRS:SPEC:58 | 2 | 3.2 | (deploy with Servlet container)If an Application subclass is present that is not being handled by an existing servlet then the servlet added by the ContainerInitializer MUST be named with the fully qualiﬁed name of the Application subclass. If the Application subclass is annotated with @ApplicationPath and no servlet-mapping exists for the added servlet then a new servlet mapping is added with the value of the @ApplicationPath annotation with ”/*” appended otherwise the existing mapping is used. If the Application subclass is not annotated with @ApplicationPath then the application MUST be packaged with a web.xml that speciﬁes a servlet mapping for the added servlet. It is an error for more than one application to be deployed at the same effective servlet mapping | true |  | false | platform | active | true
JAXRS:SPEC:59 | 2 | 3.2 | (deploy with Servlet container)In either of the latter two cases, if both Application.getClasses and Application.getSingletons return an empty list then all root resource classes and providers packaged in the web application MUST be included in the published RESTful Web Services application. If either getClasses or getSingletons return a non-empty list then only those classes or singletons returned MUST be included in the published RESTful Web Services application. | true |  | false | platform | active | true
JAXRS:SPEC:60 | 2 | 3.2 | (deploy with Servlet container)If not using the Servlet 3 framework pluggability mechanism (e.g. in a pre-Servet 3.0 container), the servlet-class or filter-class element of the web.xml descriptor SHOULD name the RESTful Web Services implementation-supplied servlet or ﬁlter class respectively. The Application subclass SHOULD be identiﬁed using an init-param with a param-name of jakarta.ws.rs.Application. | true |  | false | platform | active | true
JAXRS:SPEC:61 | 3 | 7.1 | The normalized request URI MUST be reflected in the URIs obtained from an injected UriInfo. | true |  | false | technology | active | true
JAXRS:SPEC:62 | 4 | 2.1 | The following describes the logical1 steps taken by a RESTful Web Services implementation when mapping a request entity body to a Java method parameter | true |  | false | technology | active | true
JAXRS:SPEC:62.1 | 4 | 2.1 | Obtain the media type of the request. If the request does not contain a Content-Type header then use application/octet-stream | true |  | false | technology | active | true
JAXRS:SPEC:62.2 | 4 | 2.1 | Select the set of MessageBodyReader classes that support the media type of the request, see Section 4.2.3. | true |  | false | technology | active | true
JAXRS:SPEC:62.3 | 4 | 2.1 | Iterate through the selected MessageBodyReader classes and, utilizing the isReadable method of each, choose a MessageBodyReader provider that supports the desired Java type | true |  | false | technology | active | true
JAXRS:SPEC:62.4 | 4 | 2.1 | If step 4 locates a suitable MessageBodyReader then use its readFrom method to map the entity body to the desired Java type | true |  | false | technology | active | true
JAXRS:SPEC:62.5 | 4 | 2.1 | Else generate a WebApplicationException that contains an unsupported media type response (HTTP 415 status) and no entity. The exception MUST be processed as described in Section 3.3.4. | true |  | false | technology | active | true
JAXRS:SPEC:63 | 4 | 2.2 | The following describes the logical steps taken by a RESTful Web Services implementation when mapping a return value to a response entity body | true |  | false | technology | active | true
JAXRS:SPEC:63.1 | 4 | 2.2 | Obtain the object that will be mapped to the response entity body. For a return type of Response or subclasses the object is the value of the entity property, for other return types it is the returned object. | true |  | false | technology | active | true
JAXRS:SPEC:63.2 | 4 | 2.2 | Select the set of MessageBodyWriter providers that support (see Section 4.2.3) the object and media type of the response entity body. | true |  | false | technology | active | true
JAXRS:SPEC:63.3 | 4 | 2.2 | Sort the selected MessageBodyWriter providers with a primary key of generic type where providers whose generic type is the nearest superclass of the object class are sorted first and a secondary key of media type (see Section 4.2.3). | true |  | false | technology | active | true
JAXRS:SPEC:63.4 | 4 | 2.2 | Iterate through the sorted MessageBodyWriter providers and, utilizing the isWriteable method of each, choose an MessageBodyWriter that supports the object that will be mapped to the entity body. | true |  | false | technology | active | true
JAXRS:SPEC:63.5 | 4 | 2.2 | If step 5 locates a suitable MessageBodyWriter then use its writeTo method to map the object to the entity body | true |  | false | technology | active | true
JAXRS:SPEC:63.6 | 4 | 2.2 | Else generate a WebApplicationException with an internal server error response (HTTP 500 status) and no entity. The exception MUST be processed as described in Section 3.3.4 | true |  | false | technology | active | true
JAXRS:SPEC:64 | 5 | 1 | Client instances can be configured by calling the configuration method; the object returned, of type Configuration provides access to providers, properties and features | true |  | false | technology | removed | true
JAXRS:SPEC:65 | 5 | 2 | Conceptually, the steps required to submit a request are the following: (i) obtain an instance of Client (ii) create a WebTarget (iii) create a request from the WebTarget and (iv) submit a request or get a prepared Invocation for later submission | true |  | false | technology | active | true
JAXRS:SPEC:66 | 5 | 3 | WebTarget instances are immutable with respect to their URI (or URI template): methods for specifying additional path segments and parameters return a new instance of WebTarget. | true |  | false | technology | active | true
JAXRS:SPEC:67 | 5 | 3 | However, WebTarget instances are mutable with respect to their configuration. Thus, configuring a WebTarget does not create new instances | true |  | false | technology | active | true
JAXRS:SPEC:68 | 5 | 3 | Note that changes to hello’s configuration do not affect base, i.e. inheritance performs a deep copy of the configuration. | true |  | false | technology | active | true
JAXRS:SPEC:69 | 5 | 4 | RESTful Web Services implementations are REQUIRED to use entity providers | true |  | false | technology | active | true
JAXRS:SPEC:70 | 5 | 4 | See Section 4.2.4 for a list of entity providers that MUST be supported by all RESTful Web Services implementations | true |  | false | technology | active | true
JAXRS:SPEC:71 | 5 | 5 | The mapping calls Invocation.invoke() to execute the invocation synchronously; asynchronous execution is also supported by calling Invocation.submit(). | true |  | false | technology | active | true
JAXRS:SPEC:72 | 5 | 6 | The following Client API types are configurable: Client, Invocation, Invocation.Builder and WebTarget. Configuration methods are inherited from the Configurable interface implemented by all these classes. | true |  | false | technology | active | true
JAXRS:SPEC:73 | 5 | 6 | This interface supports configuration of: Features, Properties, Providers | true |  | false | technology | active | true
JAXRS:SPEC:74 | 5 | 6 | However, any additional changes to the instance of WebTarget will not impact the Client’s configuration and vice versa. | true |  | false | technology | active | true
JAXRS:SPEC:75 | 4 | 2.4 | When reading zero-length request entities all pre-packaged MessageBodyReader implementations, except the JAXB-related one and those for the (boxed) primitive types above, MUST create a corresponding Java object that represents zero-length data; they MUST NOT return null. | true |  | false | technology | active | true
JAXRS:SPEC:76 | 4 | 2.4 | The pre-packaged JAXB and the prepackaged primitive type MessageBodyReader’s MUST throw a BadRequestException (400 status) for zero-length request entities. | true |  | false | technology | active | true
JAXRS:SPEC:77 | 3 | 1.2 | A public constructor MAY include parameters annotated with one of the following: | true |  | false | technology | active | true
JAXRS:SPEC:77.1 | 3 | 1.2 | @Context | true |  | false | technology | active | true
JAXRS:SPEC:77.2 | 3 | 1.2 | @HeaderParam | true |  | false | technology | active | true
JAXRS:SPEC:77.3 | 3 | 1.2 | @CookieParam | true |  | false | technology | active | true
JAXRS:SPEC:77.4 | 3 | 1.2 | @MatrixParam | true |  | false | technology | active | true
JAXRS:SPEC:77.5 | 3 | 1.2 | @QueryParam | true |  | false | technology | active | true
JAXRS:SPEC:77.6 | 3 | 1.2 | @PathParam | true |  | false | technology | active | true
JAXRS:SPEC:78 | 3 | 5 | When accepting multiple media types, clients may indicate preferences by using a relative quality factor known as the q parameter. The value of the q parameter, or q-value, is used to sort the set of accepted | true |  | false | technology | active | true
JAXRS:SPEC:79 | 3 | 5 | A server can also indicate media type preference using the qs parameter; server preference is only examined when multiple media types are accepted by a client with the same q-value. | true |  | false | technology | active | true
JAXRS:SPEC:80 | 4 | 3 | Context providers MAY return null from the getContext method if they do not wish to provide their context for a particular Java type. | true |  | false | technology | active | true
JAXRS:SPEC:81 | 4 | 3.1 | Context provider implementations MAY restrict the media types they support using the @Produces annotation. The absence of this annotation is equivalent to its inclusion with media type (“*/*”), i.e. absence implies that any media type is supported. | true |  | false | technology | active | true
JAXRS:SPEC:82 | 4 | 4 | When a resource class or provider method throws an exception for which there is an exception mapping provider, the matching provider is used to obtain a Response instance. The resulting Response is processed as if a web resource method had returned the Response, see Section 3.3.3. In particular, a mapped Response MUST be processed using the ContainerResponse filter chain defined in Chapter 6. | true |  | false | technology | active | true
JAXRS:SPEC:83 | 4 | 4 | To avoid a potentially infinite loop, a single exception mapper must be used during the processing of a request and its corresponding response. RESTful Web Services implementations MUST NOT attempt to map exceptions thrown while processing a response previously mapped from an exception. Instead, this exception MUST be processed as described in steps 3 and 4 in Section 3.3.4. | true |  | false | technology | active | true
JAXRS:SPEC:84 | 6 | 1 | RESTful Web Services implementations are REQUIRED to call registered interceptors when mapping representations to Java types and vice versa. | true |  | false | technology | active | true
JAXRS:SPEC:85 | 6 | 2 | Request filters implementing ClientRequestFilter or ContainerRequestFilter can stop the execution of their corresponding chains by calling abortWith(Response) in their corresponding context object. If this method is invoked, RESTful Web Services implementations are REQUIRED to abort execution of the chain and treat the response object as if produced by calling the resource method (Server API) or executing the HTTP invocation (Client API). | true |  | false | technology | active | true
JAXRS:SPEC:86 | 6 | 3 | RESTful Web Services implementations MUST use the last parameter values set in the context object when calling the wrapped methods MessageBodyReader.readFrom and MessageBodyWrite.writeTo. | true |  | false | technology | active | true
JAXRS:SPEC:87 | 6 | 5.2 | Binding annotations that decorate resource classes apply to all the resource methods defined in them. A filter or interceptor class can be decorated with multiple binding annotations. | true |  | false | technology | active | true
JAXRS:SPEC:88 | 6 | 5.2 | Similarly, a resource method can be decorated with multiple binding annotations. Each binding annotation instance in a resource method denotes a set of filters and interceptors whose class definitions are decorated with that annotation (possibly among others). The final set of (static) filters and interceptors is the union of all these sets | true |  | false | technology | active | true
JAXRS:SPEC:89 | 6 | 5.2 | returning filters or interceptors from the methods getClasses or getSingletons in an application subclass will bind them globally only if they are not decorated with a name binding annotation. If they are decorated with at least one name binding annotation, the application subclass must be annotated as shown above in order for those filters or interceptors to be globally bound | true |  | false | technology | active | true
JAXRS:SPEC:90 | 6 | 7.1 | When a filter or interceptor method throws an exception, the RESTful Web Services runtime will attempt to map the exception as described in Section 4.5. As explained in Section 4.4, an application can supply exception mapping providers to customize this mapping | true |  | false | technology | active | true
JAXRS:SPEC:91 | 6 | 7.1 | At most one exception mapper will be used in a single request processing cycle to avoid potentially infinite loops. A response mapped from an exception MUST be filtered as follows | true |  | false | technology | active | true
JAXRS:SPEC:91.1 | 6 | 7.1 | If a web resource had been matched before the exception was thrown, then all the filters in the ContainerResponse chain for that resource MUST be invoked; | true |  | false | technology | active | true
JAXRS:SPEC:91.2 | 6 | 7.1 | Otherwise, only globally bound filters in the ContainerResponse chain MUST be invoked | true |  | false | technology | active | true
JAXRS:SPEC:92 | 6 | 6 | Execution chains for extension points ContainerRequest, PreMatchContainerRequest, ClientRequest, ReadFrom and WriteTo are sorted in ascending order; the lower the number the higher the priority. Execution chains for extension points ContainerResponse and ClientResponse are sorted in descending order; the higher the number the higher the priority. | true |  | false | technology | active | true
JAXRS:SPEC:93 | 10 | 2 | This section describes the types of context available to | true |  | false | technology | active | true
JAXRS:SPEC:93.1 | 10 | 2 | Application subclasses | true |  | false | technology | active | true
JAXRS:SPEC:93.2 | 10 | 2 | resource classes | true |  | false | technology | active | true
JAXRS:SPEC:93.3 | 10 | 2 | providers | true |  | false | technology | active | true
JAXRS:SPEC:94 | 10 | 2.1 | The instance of the application-supplied Application subclass can be injected into a class field or method parameter using the @Context annotation. | true |  | false | technology | active | true
JAXRS:SPEC:95 | 10 | 2.2 | An instance of UriInfo can be injected into a class field or method parameter using the @Context annotation. | true |  | false | technology | active | true
JAXRS:SPEC:96 | 10 | 2.3 | An instance of HttpHeaders can be injected into a class field or method parameter using the @Context annotation. | true |  | false | technology | active | true
JAXRS:SPEC:97 | 10 | 2.4 | An instance of Request can be injected into a class field or method parameter using the @Context annotation. | true |  | false | technology | active | true
JAXRS:SPEC:98 | 10 | 2.5 | An instance of SecurityContext can be injected into a class field or method parameter using the @Context annotation. | true |  | false | technology | active | true
JAXRS:SPEC:99 | 10 | 2.6 | An instance of Providers can be injected into a class field or method parameter using the @Context annotation. | true |  | false | technology | active | true
JAXRS:SPEC:100 | 10 | 2.7 | It (ResourceContext) can be injected to help with creation and initialization, or just initialization, of instances created by an application. | true |  | false | technology | active | true
JAXRS:SPEC:101 | 7 | 5 | RESTful Web Services implementations MUST follow the constraint annotation rules defined in Bean Validation 1.1. JSR | true |  | false | technology | active | true
JAXRS:SPEC:102 | 7 | 6 | RESTful Web Services implementations MUST provide a default exception mapper (see Section 4.4) for jakarta.validation.ValidationException according to the following rules | true |  | false | technology | active | true
JAXRS:SPEC:102.1 | 7 | 6 | If the exception is of type jakarta.validation.ValidationException or any of its subclasses excluding jakarta.validation.ConstraintViolationException, then it is mapped to a response with status code 500 (Internal Server Error). | true |  | false | technology | active | true
JAXRS:SPEC:102.2 | 7 | 6 | If the exception is an instance of jakarta.validation.ConstraintViolationException, then: (a) If the exception was thrown while validating a method return type, then it is mapped to a response with status code 500 (Internal Server Error) 1 | true |  | false | technology | active | true
JAXRS:SPEC:102.3 | 7 | 6 | If the exception is an instance of jakarta.validation.ConstraintViolationException, then: (b) Otherwise, it is mapped to a response with status code 400 (Bad Request). | true |  | false | technology | active | true
JAXRS:SPEC:103 | 8 | 2.1 | RESTful Web Services implementations are REQUIRED to generate a ServiceUnavailableException, a subclass of WebApplicationException with its status set to 503, if the timeout value is reached and no timeout handler is registered. | true |  | false | technology | active | true
JAXRS:SPEC:104 | 8 | 2.1 | The exception MUST be processed as described in section 3.3.4. | true |  | false | technology | active | true
JAXRS:SPEC:105 | 8 | 2.1 | If a registered timeout handler resets the timeout value or resumes the connection and returns a response, RESTful Web Services implementations MUST NOT generate an exception. | true |  | false | technology | active | true
JAXRS:SPEC:106 | 8 | 3 | When an EJB method is annotated with @Asynchronous, the EJB container automatically allocates the necessary resources for its execution. | true |  | false | technology | active | true
JAXRS:SPEC:107 | 11 | 2.6 | In a product that supports the Java API for JSON Processing (JSON-P) [15], implementations MUST support entity providers for the following types: JsonStructure, JsonObject and JsonArray. Therefore, the standard set of entity providers from Section 4.2.4 is extended to support these types in combinations with the application/json media type. | true |  | false | technology | active | true
JAXRS:SPEC:108 | 3 | 4 | The value of the annotation is automatically encoded | true |  | false | technology | active | true
JAXRS:SPEC:109 | 3 | 7.3 | Converting URI Templates to Regular Expressions | true |  | false | technology | active | true
JAXRS:SPEC:110 | 4 | 1 | A RESTful Web Services implementation that supports automatic discovery of classes MUST process only those classes that are annotated with @Provider. | true |  | false | technology | active | true
JAXRS:SPEC:111 | 4 | 5.1 | When a provider method throws an exception, the RESTful Web Services server runtime will attempt to map the exception to a suitable HTTP response in the same way as described for methods and locators in Section 3.3.4. | true |  | false | technology | active | true
JAXRS:SPEC:112 | 4 | 5.1 | If the exception is thrown while generating a response, RESTful Web Services implementations are required to map the exception only when the response has not been committed yet. | true |  | false | technology | active | true
JAXRS:SPEC:113 | 4 | 5.2 | When a provider method throws an exception, the RESTful Web Services client runtime will map it to an instance of ProcessingException if thrown while processing a request, and to a ResponseProcessingException if thrown while processing a response. | true |  | false | technology | active | true
JAXRS:SPEC:114 | 5 | 6.1 | filters and interceptors are defined as RESTful Web Services providers. Therefore, they can be registered in any of the configurable types | true |  | false | technology | active | true
JAXRS:SPEC:115 | 6 | 1 | Filters and entity interceptors are providers and, as such, may be annotated with @Provider for automatic discovery | true |  | false | technology | active | true
JAXRS:SPEC:116 | 6 | 6 | Execution chains for extension points ContainerRequest, PreMatchContainerRequest, ClientRequest, ReadFrom and WriteTo are sorted in ascending order; the lower the number the higher the priority. Execution chains for extension poits ContainerResponse and ClientResponse are sorted in descending order; the higher the number the higher the priority. | true |  | false | technology | active | true
JAXRS:SPEC:117 | 6 | 7.2 | When a filter or interceptor method throws an exception, the client runtime will process the exception as described in Section 4.5.2 | true |  | false | technology | active | true
JAXRS:SPEC:118 | 7 | 1 | These constraint annotations are not restricted to method parameters, they can be used in any location in which the RESTful Web Services binding annotations are allowed with the exception of constructors and property setters. Constraint annotations are also allowed on resource classes. | true |  | false | technology | active | true
JAXRS:SPEC:119 | 7 | 2 | Constraint annotations must also define a groups element to indicate which processing groups they are associated with. If no groups are specified (as in the example above) the Default group is assumed. For simplicity, RESTful Web Services implementations are NOT REQUIRED to support processing groups other than Default. | true |  | false | technology | active | true
JAXRS:SPEC:120 | 7 | 3 | Response entity bodies returned from resource methods can be validated in a similar manner by annotating the resource method itself. | true |  | false | technology | active | true
JAXRS:SPEC:121 | 7 | 4 | According to BeanValidation 1.1 JSR, validation is enabled by default only for the so called constrained methods. Getter methods as defined by the Java Beans specification are not constrained methods, so they will not be validated by default. | true |  | false | technology | active | true
JAXRS:SPEC:122 | 10 | 2.8 | Both the client and the server runtime configurations are available for injection via @Context. These configurations are available for injection in providers (client or server) and resource classes (server only) | true |  | false | technology | active | true
JAXRS:SPEC:123 | 11 | 2.1 | Injection of Servlet-defined types is possible using the @Context annotation. Additionally, web application’s <context-param> and servlet’s <init-param> can be used to define application properties passed to server-side features or injected into server-side RESTful Web Services components. See Javadoc for Application.getProperties for more information. | true |  | false | technology | active | true
JAXRS:SPEC:124 | 3 | 3 | A request method designator is a runtime annotation that is annotated with the @HttpMethod annotation. RESTful Web Services defines a set of request method designators for the common HTTP methods: @GET, @POST, @PUT, @DELETE, @PATCH, @HEAD and @OPTIONS. | true |  | false | technology | active | true
JAXRS:SPEC:125 | 3 | 4.1 | A set of sub-resource methods annotated with the same URI template value are functionally equivalent to a similarly annotated sub-resource locator that returns an instance of a resource class with the same set of resource methods. | true |  | false | technology | active | true
JAXRS:SPEC:126 | 4 | 1.4 | Therefore, an application-supplied provider MUST always be preferred over a pre-packaged one if a single one is required. | true |  | false | technology | active | true
JAXRS:SPEC:127 | 4 | 1.4 | Application-supplied providers may be annotated with @Priority. If two or more providers are candidates for a certain task, the one with the highest priority is chosen | true |  | false | technology | active | true
JAXRS:SPEC:128 | 8 | 2.2 | An alternative approach to the injection of AsyncResponse is for a resource method to return an instance of CompletionStage as an indication to the underlying RESTful Web Services implementation that asynchronous processing is enabled. | true |  | false | technology | active | true
JAXRS:SPEC:129 | 11 | 2.6 | In a product that supports the Java API for JSON Processing (JSON-P) [18], implementations MUST support entity providers for JsonValue and all of its sub-types: JsonString and JsonNumber. | true |  | false | technology | active | true
JAXRS:SPEC:130 | 11 | 2.7 | In a product that supports the Java API for JSON Binding (JSON-B) [19], implementations MUST support entity providers for all Java types supported by JSON-B in combination with the application/json media type. Note that if JSON-B and JSON-P are both supported in the same environment, entity providers for JSON-B take precedence over those for JSON-P for all types except JsonValue and its sub-types. | true |  | false | technology | active | true
JAXRS:SPEC:131 | 2 | 3.1 | There are two alternative ways of publishing on Java SE: Creating SE endpoints directly or using the SE bootstrap API. A compliant implementation MUST support both alternatives on Java SE. | true |  | false | technology | active | false
JAXRS:SPEC:132 | 2 | 3.1 | In a Java SE environment a configured instance of an endpoint class can be obtained using the createEndpoint method of RuntimeDelegate. The application supplies an instance of Application and the type of endpoint required. An implementation MAY support zero or more endpoint types of any desired type. An implementation that supports publication via JAX-WS MUST support createEndpoint with an endpoint type of jakarta.xml.ws.Provider. JAX-WS describes how a Provider based endpoint can be published in an SE environment. | true |  | false | technology | active | false
JAXRS:SPEC:133 | 2 | 3.1 | In a Java SE environment an application can be published using an embedded HTTP server bootstrapped by the implementation. An application invokes SeBootstrap.start(app, config) with an implementation of Application and a configuration built by calling build() on a configuration builder. The builder is created by SeBootstrap.Configuration.builder() and assembles all information needed to configure the embedded HTTP server using properties. A compliant implementation MUST support all properties explicitly defined by SeBootstrap.Configuration, but MAY support additional properties using a product-specific namespace prefix.The namespace prefix jakarta is reserved and MUST NOT be extended by vendors, but only by future revisions of the Jakarta RESTful Web Services API, Javadoc and / or specification. | true |  | false | technology | active | false
JAXRS:SPEC:134 | 3 | 3.2 | For resource methods that consume multipart/form-data media types, the @FormParam annotation may be used on jakarta.ws.rs.core.EntityPart parameters. | true |  | false | technology | active | false
JAXRS:SPEC:135 | 3 | 5.2 | The multipart/form-data media type enables requests to send multiple entities (parts) as a single entity. Each part contains its own set of headers, media type and content. There are a few different ways to consume these requests in a resource method. First, a resource method may contain an entity parameter of type, List. Another approach is to use @FormParam parameters where the value in the annotation corresponds to the name of the part. The parameter type may be a jakarta.ws.rs.core.EntityPart, a java.io.InputStream, or a String. The only way to access the headers for a particular part is to use the EntityPart type. The InputStream and String types will only provide the content of the part. Note that parts of a multipart entity can be quite large, so care should be taken when using String parameter types as that will load the entire content of the part into the Java heap. When converting the part’s content, the implementation MUST use the encoding charset specified in the part’s Content-Type header, or UTF-8 if the charset is not specified in the header. | true |  | false | technology | active | false
JAXRS:SPEC:136 | 4 | 1.2 | On runtime initialization, an implementation MUST discover and register certain service providers in jakarta.ws.rs.core.Configuration runtime configurations, if and only if service loading is enabled. Service loading is enabled, except when there is an Application subclass whose getProperties method returns a map which contains the key jakarta.ws.rs.loadServices with a value of Boolean.FALSE. | true |  | false | technology | active | true
JAXRS:SPEC:137 | 4 | 1.2 | For each service X, where X is jakarta.ws.rs.core.Feature or jakarta.ws.rs.container.DynamicFeature, the set of providers to be registered MUST be determined as follows: • first, register all providers discovered with ServiceLoader.load(X.class) •additionally, register all providers discovered with ServiceLoader.load(X.class, X.class.getClassLoader()) | true |  | false | technology | active | true
JAXRS:SPEC:138 | 4 | 4 | A JAX-RS implementation MUST include a default exception mapping provider that implements ExceptionMapper and which SHOULD set the response status to 500. When the default exception mapping provider handles a WebApplicationException, it MUST return the embedded Response, and it MUST respect the status code in the Response. Any registered CompletionCallback MUST be invoked with an unmapped exception before the default exception mapping provider maps the unmapped exception to a Response. | true |  | false | technology | active | true