## Jakarta RESTful Web Services - 3.0
Specification Assertion Detail

Totals | Total | Active | Deprecated | Removed
# of Assertions | 233 | 231 | 0 | 2
# of Required Assertions | 230 | 228 | 0 | 2
# of Optional Assertions | 3 | 3 | 0 | 0

ID | Chapter | Section | Description | Required | Dependency | Implementation Specific | Defined by | Status | Testable
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS:SPEC:3.1 | 3 | 2 | @MatrixParam Extracts the value of a URI matrix parameter. | true |  | false | technology | active | true
JAX-RS:SPEC:3.2 | 3 | 2 | @QueryParam Extracts the value of a URI query parameter. | true |  | false | technology | active | true
JAX-RS:SPEC:3.3 | 3 | 2 | @PathParam Extracts the value of a URI template parameter. | true |  | false | technology | active | true
JAX-RS:SPEC:3.4 | 3 | 2 | @CookieParam Extracts the value of a cookie. | true |  | false | technology | active | true
JAX-RS:SPEC:3.5 | 3 | 2 | @HeaderParam Extracts the value of a header. | true |  | false | technology | active | true
JAX-RS:SPEC:3.6 | 3 | 2 | @Context Injects an instance of a supported resource, | true |  | false | technology | active | true
JAX-RS: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
JAX-RS: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
JAX-RS:SPEC:5.1 | 3 | 2 | Primitive types. | true |  | false | technology | active | true
JAX-RS:SPEC:5.2 | 3 | 2 | Types that have a constructor that accepts a single String argument. | true |  | false | technology | active | true
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS:SPEC:5.6 | 3 | 2 | Types for which a ParamConverter is available via a registered ParamConverterProvider | true |  | false | technology | active | true
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS:SPEC:10 | 3 | 2 | Exceptions MUST be processed as described in section 3.3.4. | true |  | false | technology | active | true
JAX-RS:SPEC:11 | 3 | 3.1 | Only public methods may be exposed as resource methods. | true |  | false | technology | active | true
JAX-RS: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
JAX-RS:SPEC:12.1 | 3 | 3.2 | The DefaultValue annotation may be used to supply a default value for parameters | true |  | false | technology | active | true
JAX-RS: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
JAX-RS: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
JAX-RS:SPEC:13 | 3 | 3.2.1 | Resource methods MUST have at most one entity parameter. | true |  | false | technology | active | false
JAX-RS: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
JAX-RS:SPEC:14.1 | 3 | 3.3 | void: Results in an empty entity body with a 204 status code. | true |  | false | technology | active | true
JAX-RS: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
JAX-RS:SPEC:14.3 | 3 | 3.3 | Response: A null return value results in a 204 status code. | true |  | false | technology | active | true
JAX-RS: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
JAX-RS: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
JAX-RS:SPEC:14.6 | 3 | 3.3 | GenericEntity: a null return value results in a 204 status code. | true |  | false | technology | active | true
JAX-RS: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
JAX-RS:SPEC:14.8 | 3 | 3.3 | Other: a null return value results in a 204 status code. | true |  | false | technology | active | true
JAX-RS: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
JAX-RS:SPEC:15.1 | 3 | 3.3 | Return Type | true |  | false | technology | active | true
JAX-RS:SPEC:15.2 | 3 | 3.3 | Returned Instance | true |  | false | technology | active | true
JAX-RS:SPEC:15.3 | 3 | 3.3 | Raw Type | true |  | false | technology | active | true
JAX-RS:SPEC:15.4 | 3 | 3.3 | Generic Type | true |  | false | technology | active | true
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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 | active | true
JAX-RS: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 | active | false
JAX-RS:SPEC:17 | 3 | 3.5 | On receipt of a HEAD request an implementation MUST either: | true |  | false | technology | active | true
JAX-RS:SPEC:17.1 | 3 | 3.5 | Call a method annotated with a request method designator for HEAD | true |  | false | technology | active | true
JAX-RS: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
JAX-RS:SPEC:18 | 3 | 3.5 | On receipt of an OPTIONS request an implementation MUST either: | true |  | false | technology | active | true
JAX-RS: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
JAX-RS:SPEC:18.2 | 3 | 3.5 | Generate an automatic response from the declared metadata of the matching class. | true |  | false | technology | active | true
JAX-RS:SPEC:19 | 3 | 4 | Template parameters can optionally specify the regular expression used to match their values. | false |  | false | technology | active | true
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS:SPEC:23 | 3 | 6 | Annotations on a super-class take precedence over those on an implemented interface. | true |  | false | technology | active | true
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS:SPEC:25.10 | 3 | 7.2 | n2/m2 /> n1/m1 and v1 > v2 | true |  | false | technology | active | true
JAX-RS:SPEC:25.11 | 3 | 7.2 | n2/m2 /> n1/m1 and v1 = v2 and v1' > v2' | true |  | false | technology | active | true
JAX-RS:SPEC:25.12 | 3 | 7.2 | n2/m2 /> n1/m1 and v1 = v2 and v1' = v2' and v1'' <= v2'' | true |  | false | technology | active | true
JAX-RS:SPEC:26 | 3 | 8 | The following algorithm is used to determine the response media type, Mselected, at run time | true |  | false | technology | active | true
JAX-RS: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
JAX-RS: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
JAX-RS:SPEC:26.3 | 3 | 8 | Else if the class is annotated with @Produces, set P = V (class). | true |  | false | technology | active | true
JAX-RS: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
JAX-RS:SPEC:26.5 | 3 | 8 | If P = , set P = ‘*/*’ | true |  | false | technology | active | false
JAX-RS:SPEC:26.6 | 3 | 8 | If A = , set A = ‘*/*’ | true |  | false | technology | active | true
JAX-RS: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
JAX-RS: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
JAX-RS:SPEC:26.9 | 3 | 8 | If M contains ‘*/*’ or ‘application/*’, set Mselected = ‘application/octet-stream’, finish. | true |  | false | technology | active | false
JAX-RS: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
JAX-RS:SPEC:27 | 4 | 1.2 | 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
JAX-RS:SPEC:28 | 4 | 1.2 | 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
JAX-RS:SPEC:29 | 4 | 1.2 | 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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS:SPEC:33.1 | 4 | 2.4 | byte[] All media types (*/*). | true |  | false | technology | active | true
JAX-RS:SPEC:33.2 | 4 | 2.4 | java.lang.String All media types (*/*). | true |  | false | technology | active | true
JAX-RS:SPEC:33.3 | 4 | 2.4 | java.io.InputStream All media types (*/*). | true |  | false | technology | active | true
JAX-RS:SPEC:33.4 | 4 | 2.4 | java.io.Reader All media types (*/*). | true |  | false | technology | active | true
JAX-RS:SPEC:33.5 | 4 | 2.4 | java.io.File All media types (*/*). | true |  | false | technology | active | true
JAX-RS:SPEC:33.6 | 4 | 2.4 | jakarta.activation.DataSource All media types (*/*). | true |  | false | technology | active | true
JAX-RS:SPEC:33.7 | 4 | 2.4 | javax.xml.transform.Source XML types (text/xml, application/xml and application/*+xml). | true |  | false | technology | active | true
JAX-RS: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
JAX-RS:SPEC:33.9 | 4 | 2.4 | MultivaluedMap<String,String> Form content (application/x-www-form-urlencoded). | true |  | false | technology | active | true
JAX-RS:SPEC:33.10 | 4 | 2.4 | StreamingOutput All media types (*/*), MessageBodyWriter only. | true |  | false | technology | active | true
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS:SPEC:45 | 11 | 1 | Servlet ﬁlters may trigger consumption of a request body by accessing request parameters. | true |  | false | platform | active | true
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS:SPEC:69 | 5 | 4 | RESTful Web Services implementations are REQUIRED to use entity providers | true |  | false | technology | active | true
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS:SPEC:73 | 5 | 6 | This interface supports configuration of: Features, Properties, Providers | true |  | false | technology | active | true
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS:SPEC:77 | 3 | 1.2 | A public constructor MAY include parameters annotated with one of the following: | true |  | false | technology | active | true
JAX-RS:SPEC:77.1 | 3 | 1.2 | @Context | true |  | false | technology | active | true
JAX-RS:SPEC:77.2 | 3 | 1.2 | @HeaderParam | true |  | false | technology | active | true
JAX-RS:SPEC:77.3 | 3 | 1.2 | @CookieParam | true |  | false | technology | active | true
JAX-RS:SPEC:77.4 | 3 | 1.2 | @MatrixParam | true |  | false | technology | active | true
JAX-RS:SPEC:77.5 | 3 | 1.2 | @QueryParam | true |  | false | technology | active | true
JAX-RS:SPEC:77.6 | 3 | 1.2 | @PathParam | true |  | false | technology | active | true
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS:SPEC:91.2 | 6 | 7.1 | Otherwise, only globally bound filters in the ContainerResponse chain MUST be invoked | true |  | false | technology | active | true
JAX-RS: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
JAX-RS:SPEC:93 | 10 | 2 | This section describes the types of context available to | true |  | false | technology | active | true
JAX-RS:SPEC:93.1 | 10 | 2 | Application subclasses | true |  | false | technology | active | true
JAX-RS:SPEC:93.2 | 10 | 2 | resource classes | true |  | false | technology | active | true
JAX-RS:SPEC:93.3 | 10 | 2 | providers | true |  | false | technology | active | true
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS:SPEC:104 | 8 | 2.1 | The exception MUST be processed as described in section 3.3.4. | true |  | false | technology | active | true
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS:SPEC:108 | 3 | 4 | The value of the annotation is automatically encoded | true |  | false | technology | active | true
JAX-RS:SPEC:109 | 3 | 7.3 | Converting URI Templates to Regular Expressions | true |  | false | technology | active | true
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS: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
JAX-RS:SPEC:126 | 4 | 1.3 | 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
JAX-RS:SPEC:127 | 4 | 1.3 | 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
JAX-RS: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
JAX-RS: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
JAX-RS: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