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 JAX-RS runtime and MUST have a public constructor for which the JAX-RS 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 fields 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 field 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 field and bean properties are not modified 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 satisfies 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 fields and properties. | true |
| false | technology | active | true |
JAX-RS:SPEC:8 | 3 | 2 | A WebApplicationException thrown during construction of field 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 field 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 field 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 field 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 fields 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 field 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 specified 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-specific 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 JAX-RS 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 JAX-RS runtime and MUST have a public constructor for which the JAX-RS 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, JAX-RS 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 | javax.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-defined resource. | true |
| false | platform | active | true |
JAX-RS:SPEC:42 | 11 | 1 | A Servlet-based implementation MUST support injection of the following Servlet-defined 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 filters 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 specification, implementations MUST support JAX-RS 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. JAX-RS 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 JAX-RS 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 JAX-RS resources is OPTIONAL. Portable applications MUST instead use fields 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 JAX-RS annotated fields 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 JAX-RS application are configured 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 configuration. | 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: javax.ws.rs.core.Application, and all root resource classes and providers packaged in the web application MUST be included in the published JAX-RS application. The application MUST be packaged with a web.xml that specifies 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 defined that has a servlet initialization parameter named: javax.ws.rs.Application, whose value is the fully qualified name of the Application subclass then no new servlet should be added by the JAX-RS 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 qualified 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 specifies 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 JAX-RS application. If either getClasses or getSingletons return a non-empty list then only those classes or singletons returned MUST be included in the published JAX-RS 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 JAX-RS implementation-supplied servlet or filter class respectively. The Application subclass SHOULD be identified using an init-param with a param-name of javax.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 JAX-RS 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 JAX-RS 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 | JAX-RS 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 JAX-RS 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. JAX-RS 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 | JAX-RS 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, JAX-RS 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 | JAX-RS 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 JAX-RS 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 | JAX-RS 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 | JAX-RS 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 | JAX-RS 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, JAX-RS 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 JAX-RS 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 JAX-RS 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, JAX-RS 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 JAX-RS 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 JAX-RS 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 JAX-RS 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, JAX-RS 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 JAX-RS 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. JAX-RS 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 JAX-RS 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 |