Jakarta RESTful Web Services
License: Other
Jakarta RESTful Web Services provides a specification document, TCK and foundational API to develop web services following the Representational State Transfer (REST) architectural pattern.
Contributions are welcome, please sign the Eclipse Contributor Agreement before submitting PRs: https://www.eclipse.org/contribute/cla
Project page: https://projects.eclipse.org/projects/ee4j.jaxrs
Mailinglist: https://accounts.eclipse.org/mailing-list/jaxrs-dev
![dependabot[bot] avatar](https://avatars.githubusercontent.com/in/29110?v=4 "dependabot[bot]")
HttpHeaders.getRequestHeaders has to return a
MultivaluedMap<java.lang.String,java.lang.String> that is case-insensitive with
regards to keys.
The problem is that MultivaluedMap extends java.util.Map and case insensitivity
is probably not implementable for the standard Map methods without violating the
specification for java.util.Map which doesn't provide for other identity
criteria than object equality, so a case insensitive implementation probably
contradicts one or more method-definitions of java.util.Map.
Furthermore the implementation of equals and hashCode isn't clear, i.e. if the
original casing of the keys is to be used for this purpose and if not (which
seems to derive from case-insensitivity) what hashCode is to be used.
Operating System: All
Platform: All
Having classes:
abstract class A {
@get @path("foo") public abstract Object get();
}
class B {
@OverRide @produces("application/xml") Document get();
}
The @produces annotation in the subclass nullifies the @get and @path annotations on the
superclass, so that operating on the subclass doesn't work. It's possible to alleviate this by replicating
the superclass annotations on the subclass, but this leads to duplication.
The use case for this is having multiple classes extending an abstract base class where the base class
dictates the methods and paths that should be support, and the subclasses provide the media type
(imagine pictures, documents etc. all sharing similar functionality).
Operating System: All
Platform: Macintosh
When you create a list of variants, you are required to call add to generate an intermediate list prior to calling build to generate the actual returned list. This can be confusing and easily missed and also seems unnecessary.
for example:
List vs = Variant.mediaTypes("a/xml", "a/json").languages("en", "fr").build();
results in an empty list, whereas
List vs = Variant.mediaTypes("a/xml", "a/json").languages("en", "fr").add().build();
actually builds the list. All other similar structure with the spec simply use build to generate the result.
[1.0, 1.1]
If no Accept-Language header is supplied the RI implementation of
HttpHeaders.getAcceptableLanguages() will return a single Locale with the
language set to "*" (as opposed to an empty list).
Similar clarification required for HttpHeaders.getAcceptableMediaTypes(). If no
Accept header s supplied the RI implementation will return a single MediaType
set to "/"
Operating System: All
Platform: Macintosh
The spec of JAX-RS 1.1 does not specify how the annotation applied to interfaces (not methods of
interfaces) should be inherited. This informations would be required in Java EE Container to fulfill the
following, taken from the spec (paragraph 6.2)
"JAX-RS annotations MAY be applied to a bean’s local interface or directly to a no-interface bean."
Without this it's not know how the following should work:
It means that EJB share the same entry points, but consumes/produces different media types.
It's also not clear how to handle EJB with business interface annotated by @path. Current reference
(Jersey) implementations ignores EJBs with such annotations and does not add them to root resources.
Please see discussion at this address:
https://jersey.dev.java.net/issues/show_bug.cgi?id=394
and
https://jersey.dev.java.net/issues/show_bug.cgi?id=396
Operating System: All
Platform: Macintosh
[2.0]
(Email from Bill Burke, http://java.net/projects/jax-rs-spec/lists/jsr339-experts/archive/2011-03/message/7)
In the message body reader/writer matching algorithm add an additional sort so that template variables take precedence. For example
@produces("application/xml")
public class FooWriter implements MessageBodyWriter
{...}
takes precedence over:
@produces("application/xml")
public class JaxbWriter implements MessageBodyWriter {...}
Users may want to override the default JAXB (or other) provider for a specific java type.
Since Content-Disposition plays a important role in multipart form data and with
many use cases of multipart form data in RESTful WS, it would make JAX-RS more
portable if ContentDispostion like API (currently an example is available in
jersey-core module) is made part of JAX-RS, as it would reduce dependency from
implementor. In fact, with the usages I have faced this is one of area where I
have to depend of Jersey directly instead of JAX-RS.
Operating System: All
Platform: All
There are a lot of different types of @context parameters that might be
injected. What I find I tend to do is ask for the ones I need, but then,
eventually, I almost always have a need for another one. There's a choice:
inject them into the method (makes method signatures unstable) or inject them
into ctor / field / setter (means that some methods will have them injected
even if they don't plan to use them, with attendant per-request performance
overhead.)Further, API layering increases the tendency for methods to ask for @context
parameters that they might not need, since you don't always know if the lower
layers are going to use it or not.What about some sort of uber-context type, which would let you dynamically
request lazily constructed context params of other types? Something likepublic void foo(@context UberJerseyContext context)
{ > SecurityContext sc = context.getSecurityContext(); > UriBuilder ub = context.getUriBuilder(); > }
which would (a) allow us to simplify the APIs that truck in partial request
handling by requiring fewer params) and (b) potentially avoid the overhead of
constructing injected objects that won't always be needed?Basically, this is a solution to the problem of "I have to ask for everything
I might need up front." It would be nice to be able to ask for some context
later, when I realize I need it.
Paul says:
What about something like the following:
public void foo(@context MetaContext context)
{ SecurityContext sc = context.get(SecurityContext.class); UriBuilder ub = context.get(UriBuilder.class); }
Operating System: All
Platform: All
JAX-RS 2.0 will standardize a client API for REST. Just as the server side of JAX-RS is extendable in multiple ways, extensibility of the client must be aligned at the same level. This includes the ability to execute methods other than the standard HTTP ones (GET, PUT, POST, DELETE etc.), especially common ones like those of WebDAV (PROPFIND, etc.) or PATCH.
To support this type of extension, it is necessary that the specification clearly mandates that an implementation of the JAX-RS 2.0 client API MUST NOT restrict the method names in any way, but that instead ANY possibly unknown or future method names MUST work.
The reason for this is that the typical implementations might rely on the Java SE class HttpURLConnection which is unable to process other methods thatn the standard HTTP ones, which leads to the fact that WebDAV and other extensions do not work. To enforce that any implementation of the client API is able to execute any kind of extension, the specification must contain clear words about the wanted behaviour.
WebDAV
It would be good to be able to have multiple sets of classes which work together to 'render' a set of
resources into a particular MIME type. As an example, imagine a sample system which is a simple music
information database (artists, CDs, and tracks). We want to be able to render these resources as HTML,
XML, or JSON (and in a manner that could be extended to other types in the future).
Keeping the renderings separate/orthogonal from each other requires that we have multiple
ExceptionMappers for the same exception which produce different media types. We tried doing
something like this:
=================
package net.gilstraps.music.html;
@Provider
@produces( "text/html" )
public class NoSuchArtistMapper implements ExceptionMapper {
// ...
}
=================
package net.gilstraps.music.xml;
@Provider
@produces( "application/music-xml" )
public class NoSuchArtistMapper implements ExceptionMapper {
// ...
}
=================
package net.gilstraps.music.json;
@Provider
@produces( "application/json" )
public class NoSuchArtistMapper implements ExceptionMapper {
// ...
}
=================
But this does not work because media type is not considered when searching for an ExceptionMapper.
Please add this enhancement to the next version of the spec, so that truly separate code bases can co-
exist even when handling generated exception.
Thanks,
Brian Gilstrap
Operating System: All
Platform: Macintosh
[2.0]
Typically, JAX-RS methods are defined by a 1:1 relation between the
annotation's (@interface's) name, and the same name provided in the @HttpMethod
value:
@HttpMethod("FOOBAR")
public @interface FOOBAR {
}
As it is rather tedious and error-prone to always repeat the same string twice,
it would be a nice feature if by default the @HttpMethod would expect this name
equalness if the value attribute was left out:
@HttpMethod // implies value="FOOBAR" by default
public @interface FOOBAR {
}
The reduces the possibility of typos (unintentional deviation of @HttpMethod's
value and annotation's interface name) and is less boring.
As this is not a major feature but just a slight improvement, and as this is
does not break the binary backwards compatibility, I want to propose the
adoption of this minor feature into JSR311 Maintenance Release 1.2.
Operating System: All
Platform: All
[2.1]
When @RolesAllowed is declared on an session bean that is also a resource class
and then the EJB may throw a AccessLocalException if the client is not authorized.
JAX-RS implementations should map this AccessLocalException to a 401 response.
Applications will of course need to correctly set up credentials and the sharing
of those between the web and ejb containers.
It remains an open issue how a JAX-RS implementation can obtain information to
return a WWW-Authenticate response header.
Operating System: All
Platform: Macintosh
[2.1]
The Semantic Web is gaining momentum, as the possiblity to access all kinds of
information using a single technology opens new types of use cases.
One of the accepted standards of The Semantic Web clearly is the RDF data
format.
So a future release of the JAX-RS specification should come with mandatory
support for automatic RDF marshalling / unnmarshalling.
The most easy way for the application author would be to just set the RDF
format using the existing MIME annotations, like @produces / @consumes.
Operating System: All
Platform: All
[2.0]
I posted along these lines a while back, but I continue to run into cases where
I need to make modifications to a URI, and there doesn't seem to be an easy way
to do it.
For instance, if my resource has URI .../color/red/width/10/height/5, I find
myself needing to redirect the client after an "edit" operation to
.../color/BLUE/width/10/height/2.
What I really want is
UriInfo.getAbsolutePathBuilder().addOrReplaceSegment("color/$","BLUE").addOrReplaceSegment("height/$
{height}
","2");
Operating System: All
Platform: Macintosh
[2.1]
provide a mechanism to be able to raise the priority of a representation when there are multiple representations - particularly if you want to override the
ordering imposed by the default sorting rules - for example that regex based paths are lower priority than non-regex methods.
For example I might have a resource like this which has both a HTML representation and XML/JSON...
public class MyResource {
@get
@path("
{template:\w*}
")
@produces(
{MediaType.TEXT_HTML}
)
public Viewable genericView(@PathParam("template") String template)
{ return new Viewable(); }
@get
@path("cheese")
@produces({MediaType.APPLICATION_XML, ...})
public Cheese cheese() {...}
@get
@path("beer")
@produces({MediaType.APPLICATION_XML, ...})
public Beer beer() {...}
}
and I might want the default representation of /cheese and /beer to be HTML views using the cheese.jsp and beer.jsp templates - as many browsers
tend to send different sets of accept headers. You typically only want to serve XML/JSON if the end user really wants it (i.e. explicitly specifies it) -
otherwise defaulting to HTML tends to be what end users would expect.
Right now the converse would be the case; it would default to XML by default since we're using a regex to avoid having to manually list all of the JSP
pages we've got HTML views for.
So either I'd like us to be able to use some kind of @priority annotation to specify the priorities of representations irrespective of the user of regex - or
maybe we can support the use of rankings of MIME types in the @Produces/@consumes text strings, rather like the Accept headers?
e.g. to make HTML the default representation - notice the use of mimeType;q=priority in the MIME strings...
@get
@path("{template:\w*}")
@produces({"text/html;q=1.0"})
public Viewable genericView(@PathParam("template") String template) { return new Viewable(); }
{"text.xml;q=0.9"}
)
public Beer beer()
{...}
}
Operating System: All
Platform: Macintosh
Summary:
Change in section 3.7.2 2 (a) "and go to step 3" to "if M is not empty go to
step 3".
Rationale:
According to the current section 3.7.2 when there is no path left after the path
of the resource class only resource methods but not sub-resource
method may be selected. I think it would be useful to be able to
return another object to handle the request also for the root of the
resource.
For example I would like the following class to delegate any request
to the instance of WidgetResource returned by WidgetResourceFactory:
@path("")
public class WidgetsResource {
@path("
{path:.*}
")
public WidgetResource findWidget(@context UriInfo uriInfo)
{ return new WidgetResourceFactory.getWidgetResourceByUri(uriInfo.getAbsolutePath()) }
}
public class WidgetResource {
@get
public Widget getDetails()
{...}
@propfind
public Object() {...}
}
The concrete use case is that in Apache Clerezza we want to redirect
to a Resource Class based on the type of the requested resource in an
underlying RDF model if no regular root resource class could be
located for the specific path. Currently we are doing this with an
explicit call back via a non-standard extension[1] of the jax-rs
implementation, however this is quite odd as for every http method
(including any extension) we need to add a new resource method to the
forwarding class.
I think a slight generalisation of the spec could satisfy our needs,
the minimalist way to achieve this would be to change in section 3.7.2
2 (a) "and go to step 3" to "if M is not empty go to step 3".
I believe such a change would also be useful in other situations, in
fact I've been writing constructs like the following several time:
@path("widgets")
public class WidgetsResource {
@get
public Widget getRootWidget(@context UriInfo uriInfo)
{ return getWidget(uriInfo); }
{path:.+}
")
public Widget getWidget(@context UriInfo uriInfo)
{...}
}
It seems awkward to have to write that extra method for when there is
no path left.
Cheers,
reto
Operating System: All
Platform: All
URL: https://jsr311.dev.java.net/servlets/ReadMsg?list=users&msgNo=1043
JAX-RS should provide a way to access an X509 certificate of the client.
Currently it seems only possible with a Servlet-Based implementation to access
this.
see https://jsr311.dev.java.net/servlets/ReadMsg?list=users&msgNo=1068
Operating System: All
Platform: All
[2.1]
It would be useful to allow applications to specify the relative quality of produced media types and to have
this taken into consideration when matching requests to methods and determining the media type of
responses. E.g. see the Apache mod_negotiation algorithm:
http://httpd.apache.org/docs/1.3/content-negotiation.html
Operating System: All
Platform: All
URL: https://jsr311.dev.java.net/servlets/ReadMsg?list=users&msgNo=746
JSR 339 will provide Hypermedia support. A first proposal will be Jersey's optional / experimental HATEOAS and Hyperlinking support based on content filtering. There are two issues with that proposal and need to be solved to provide the best value to the programmer. Note that this particular RFE is not about HATEOAS (i. e. not about "Actions") but about Hperlinking (i. e. "Relations").
(1) Link injection
The Hypermedia sample is using XmlAdapters to replace JAXB references by URIs. This is not very smart, as it puts the burden on the programmer. As he has to implement the marshalling and unmarshalling for each reference, he has to implements things that a JAX-RS engine actually knows. Instead of enforcing the programmer to do that, it would be better if JAX-RS would specify a way that automates this.
There is an experimental annoation "@ref" provided by Jersey, which does the work for the programmer, but it has shortcoming in two aspects.
(a) It is intended to work only with references of the Java types "String" and "URI", while typically JAXB object trees have references of any custom Java type but typically not "String" or "URI". Obviously linking should work with any XmlElement reference instead (or additionally), just as it is possible with XmlAdapters in the Hypermedia sample. In short: "@ref" should do what @XmlJavaTypeAdapter does plus automatically writing the XmlAdapter.
(b) It seems "@ref" doesn't guess the sub-resource locator on its own. It would be good if the JAX-RS specification would include an algorithm for automatic guessing of the sub-resource locator. For example, if there is only one method that has a return type of the referenced type and that method is annotated with @get, it can be the only sub-resource locator suited for the need of "@ref" reference-to-URI replacement and vice versay. So in that case, an algorithm is running, and that algorithm needs to be defined by the specification to prevent different results from different JAX-RS engines.
(2) Adressing fragments
In some cases it might be needed to references fragments, i. e. not entities but parts of entities. For example, there might be a sub-resource for "Order" which contains child elements of "Ordered Items". It could be the case that a different resource needs to reference not a complete order but one "Ordered Item" only (i. e. a row of the overall order containing the item's code and number of ordered items). Typically such references are implemented using URI fragments like "http://myserver/orders/12345#001" to identify within . A different example would be linking to employees being parts of an organization (not to standalone persons), or particular characteristics of items (not to general characteristics as standalone entities), etc. Just everything that couldn't live as a standalone object from a real world perspective.
When providing support for Hyperlinking in JAX-RS, it also makes sense to provide support for URI fragments. In our application for example we are using this using custom code in our product basing on Jersey 1.4 already, by the support of specialized XmlAdapters. The solution is rather simple and could be implemented ontop of (1) Link injection.
[2.0]
Path matching occurs before sub-resource HTTP method and @Consumes/Produces
matching. This can lead to cases such as:
{x}")
public String get() { ... }
@post
@path("x")
public String post() { ... }
where a GET .../x will fail with a 405 (Method Not Allowed).
This is a restriction in the JAX-RS matching algorithm. Path matching occurs
before HTTP method matching.
The @path("x") takes precedence over @path("{x}
") because it contains more
literal characters. So if the request path is .../x only the POST method will be
associated with that template.
(Note that it is a hard problem to determine if one regex is a sub-set of
another regex)
We would need to modify the JAX-RS matching algorithm to take into account the
HTTP method in section 3.7.2 bullet 2.c.i.
https://jsr311.dev.java.net/nonav/releases/1.1/spec/spec3.html#x3-350003.7.1
But then additional issues may still be possible because @Consumes/@produces is
not taken into account either, and this needs to be balanced with matching for
sub-resource locators.
Operating System: All
Platform: Macintosh
As described in the JAX-RS 2.0 JSR (http://jcp.org/en/jsr/proposalDetails?id=339)::)
The most commonly requested feature for JAX-RS 2.0 is a client API: many if not all JAX-RS implementations provide some degree of client API support. This JSR will define two client APIs, both compatible with the REST style: a low level API using a builder pattern and a higher level one leveraging the former. Common security mechanisms will also be specified. The API will not define how HTTP client implementations, such as HttpUrlConnection or the Apache HTTP client library, will plug into the API. The API will support synchronous and asynchronous response processing. WebSocket or HTTP streaming processing of responses are out of scope for this JSR and will be handled in a future revision of JAX-RS.
This issue only covers the high-level client API.
[2.0]
Can be a new feature?
On this URL: GET /mercedes/e55;color=black/2006/interior;color=tan
Mapped as: @path("/
{make}
/
{model}
/
{year}
/
{extra}
")
Can access to all "color" matrix params, for example, with:
@MatrixParam("model;color")
@MatrixParam("extra;color")Thanks to Bill Burke for example (on their book "RESTfull Java with JAX-RS)
Yes, rather than using @PathParam("model") PathSegment ps.
Can you please log an issue here:
Paul.
Operating System: All
Platform: All
[2.1]
Given: /images;offset=
{offset}
;count=
{count}/random;count={count}
Where /images is implemented using one resource, and /random using a sub-resource
If I declare @MatrixParam in the sub-resource random but the client does not
specify the "count" parameter at all, I should get null (indicating the
parameter was missing) instead of inheriting the value of count from /images.
Currently there is no obvious way to detect the real value of count for /random.
With respect to implementing the entire URL with a single Resource, it should be
possible to get:
Operating System: All
Platform: All
[2.1]
The Servlet API specifies a vendor neutral way of applying a filter chain
before a request is passed into the actual resource / the response is passed to
the actual client. Such filters are used in conjunction with JAX-RS e. g.
in "The WebDAV Project" (http://webdav.dev.java.net) to provide content
modifications "on the fly". Unfortunately this is not a general solution, since
the JAX-RS specification does not enforce a JAX-RS implementation to be basing
on the Servlet API.
On the other hand, JAX-RS's RI "Jersey" has it's own, proprietary filters
framework. This framework would allow a similar implementation that is
guaranteed to run with Jersey, even when not driven by a Servlet container.
Unfortunately this is not a general solution, since Jersey is just one of many
possible JAX-RS implementations. As a portable application should not use
prorietary solutions, this is not an option for a general purpose project
like "The WebDAV Project".
As a result, with JAX-RS 1.x there is no real one-sizes-fits-all solution,
which foils the general WORA idea underlying both, the Servlets API and JAX-RS.
Due to this situation, speaking for "The WebDAV Project", I want to suggest
that the next release of JAX-RS specifies a filter model which is mandatory to
any JAX-RS implementation.
Operating System: All
Platform: All
From Jersey issue 266:
https://jersey.dev.java.net/issues/show_bug.cgi?id=266
Seems that if there's a regex in my @path annotation then things don't work
quite as I expected.
Here's a small test
@path("/test")
public class TestResource {
@get
@path("/
{one: abc.*}")
public Response firstMethod(@PathParam("one") String one) { System.out.println("one"); System.out.println(one); return Response.noContent().build(); // 204 }
@get
@path("/{one: (?!abc).*}")
public Response secondMethod(@PathParam("one") String one) { System.out.println("two"); System.out.println(one); return Response.notModified().build(); // 304 }
")
public Response thirdMethod(@PathParam("one") String one)
{ System.out.println("three"); System.out.println(one); return Response.ok().build(); // 200 }
}
And the following results for various requests:
GET http://localhost:9998/test/abc123 -> 204
GET http://localhost:9998/test/fred -> 304
POST http://localhost:9998/test/fred > 405!! < NOT 200
This doesn't seem right. As an aside, I noticed that if I set "secondMethod" to:
@get
@path("/
{one}
")
public Response secondMethod(@PathParam("one") String one) {
Things work as expected.
Per Paul, Also editing "thirdMethod" as follows also works:
@post
@path("/
{one: (?!abc).*}
")
public Response thirdMethod(@PathParam("one") String one) {
Operating System: All
Platform: Macintosh
JAX-RS specifies that a compliant implementation has to answer OPTIONS requests
by an Allows header created automatically by inspection which HttpMethods have
been found in the resource code.
Sometimes it is necessary that a resource implements OPTIONS to provide some
more headers. Example: A WebDAV resource must return the header "DAV: 1, 2" to
indicate it's "compliance class" (strange but true, since inspecting the Allows
header would provide the same information, but this discussion is out of scope).
The problem is that the automatic Allows header will not be provided as soon as
a OPTIONS implementation is found. So the implementation must not just provide
the additional headers, but also everything that JAX-RS would do automatically.
This is not very smart.
I want to suggest that the next release of JAX-RS specifies a away how to mix
both results, the automatic one of JAX-RS and the manual one of the
implementation.
Operating System: All
Platform: All
To ensure the same behaviour on all implementations of JAX-RS, the specification should mandate how to react on RuntimeException thrown at application construction. I. e. whether to stop loading the application or whether to go on loading the application, in case (1) the application class constructor, or (2) the getClasses method or (3) the getSingletons method is throwing a RuntimeException.
For portability and WORA principle it is needed for JAX-RS users to know that they can rely upon the application getting loaded or not getting loaded when throwing such an exception. Currently Jersey is stopping to load the application, but this is not documented behaviour. There might be JAX-RS implementations ignoring RuntimeException, going on loading, leading to unpredicted behaviour. To give the programmer control on startup behaviour on ALL platforms, this JavaDoc change is needed.
Create an exception hierarchy for both the client and server side. For example:
Internally, on the server side, if JAX-RS matches a @path, but the Accept header doesn't match produced media types, the JAX-RS implementation should throw a
UnsupportedMediaTypeException
If users want custom output for that exception they can catch it via an ExceptionMapper. You'd have others for NotFoundException, NotAcceptableException, etc... each corresponding to a JAX-RS failure thrown by the runtime (not the users app).
(Email from Bill Burke, http://java.net/projects/jax-rs-spec/lists/jsr339-experts/archive/2011-03/message/8 )
Another thing we do in Resteasy is to have wrapper exceptions for:
ApplicationException - Wraps any thrown exception by the application
ReaderException - Wraps any thrown exception by a MessageBodyReader
WriterException - Wraps any thrown exception by a MessageBodyWriter
That way, if a user wants to do its own special exception handling for all thrown exceptions from an application, they can write an ExceptionMapper for ApplicationException, same goes for other instances.
On the client side, it depends what kind of higher-level framework is written on whether or not these exceptions are re-used on the client.
JSR 339 will specify a Client API. It is expected that the Jersey Client API will be proposed as a template for that API. There is an issue not covered currently with the Jersey Client API, so I'd like to address it with this RFE.
JAX-RS's Server API automatically creates Allows headers for OPTION responses, so clients can interrogate the possible invocation targets by inspection these headers. Without a particular RESTful client API, it is up to the programmer of the client to write that code.
With a RESTful Client API (in comparison to a pure HTTP Client API) people would expect that it makes processing the headers as convenient as the creation of them. As the server side fully automates the creation, they would expect that the client side also automatically processes them.
So I want to propose that the Client API has to have a method for most simple interrogation of the allowed invocation targets, not just an API to find out about which headers do exist and what value they have.
I could image a comfortable solution like this one:
The WebResource instance can be asked to provide a Collection instance of possible invocations, which serve as a starting point (factory method) for a pre-configured UriBuilder / RequestBuilder instances (pre-configure with the particularly allowed method and URLs). As with every received response an Allows header can be contained, this list has to be dynamic and change with each received response.
As there already has to be some parsing of Link headers and entity-contained action URLs for the planned HATEOS support in JAX-RS 2.0, checking the Allows header would be a natural companion. While Link and entity-contained URLs point out which actions are possible, the Allows header (in some possible services) might describe whether the current user actually is allowed to follow that link. As a Client API consumer not necessarily (even more: not typically) is the provider of the server, the Client API must be able to process and support such a scenarion to be really RESTful and flexible, and not to be just a Client API for especially JAX-RS or Jersey based services.
Proposal
To simplify the POST-Locate-GET use case (i. e. INSERT with auto-generated ID, sending back a URI containing the generated ID, GET to request all DEFAULTs applied by the database; see http://wikis.oracle.com/display/Jersey/Code+Snippets for a code sample) it would be great if there would be a UriBuilder.fromMethod(Class cls, String methodName) method. It could be implemented as simple as UriBuilder.path("").path(Class cls, String methodName).
Justification
The POST-Locate-GET use case is a common usage pattern, and described in the HTTP specification. Currently one must use rather lenghty code to create the "Location" URI. The above proposal would it make just simpler. The problem with the current workarounds is that they either are too long (several lines of code), or are not clearly supported (because UriBuilder.path("")'s JavaDocs do not clearly say that an empty String is a valid option).
JAX-RS 1.1 only uses path and media type annotations to select the method for
request dispatching however the specification also includes other request
annotations, specifically @QueryParam which could also be used in the selection
algortithm.
This enhancement would allow for overloaded java methods with different
signatures to be appropriately selected based on the presence or absence of a
named method argument, eg:
@get
public Response get()
{ return Response.ok("The search form").build(); }
@get
@QueryParam("term")
public Response get(@QueryParam("term") String term)
{ return Response.ok("The search results").build(); }
This example is invalid in JAX-RS 1.1 as both methods have the same path and
consume\produce media types.
Operating System: All
Platform: Macintosh
When parent, child resource are having two different methods but producing &
consuming same MIME type the method resolution is giving conflicts.
Scenario: Parent resource is having a general resource method which is common
for all its child resources. But a particular child needs to provide other kind
of behavior and returning incompatible return type compared to its parent class
method. But it can't simply override its parent class method to change the
behavior for the same MIME type, as the return type is incompatible.
@XmlRootElement
public class Dept {
public String name;
public Dept() { }
public Dept(String name)
{ this.name = name; }
}
@XmlRootElement
public class TechDept {
public String tech;
public TechDept() { }
public TechDept(String tech)
{ this.tech = tech; }
}
@path("parent")
public class ParentResource {
@get
public List getFromParent()
{ System.out.println("Parent resource method"); List res = new ArrayList(); res.add(new Dept("HR")); res.add(new Dept("Finance")); return res; }
}
@path("child")
public class ChildResource extends ParentResource {
// here we can't override the getFromParent() of the parent class
// as the child resource needs to send other which is incompatible
// with parent' method
@get
public List getFromChild()
{ System.out.println("Child resource method"); List res = new ArrayList(); res.add(new TechDept("Java")); res.add(new TechDept("JavaScript")); return res; }
}
When requested for the child resource, as with Jersey (even for parent
resource), the above code gives the following exception:
SEVERE: Producing media type conflict. The resource methods.....
When resource inheritance is present and when accessing a resource, considering
the class hierarchy as the second key can help resolving the resource method
(section 3.7.2-3 of jax_rs-1.1 spec doesn't tell about the inheritance clearly)
Operating System: All
Platform: All
A major benefit of HTTP is the possibility of transparent caching. Such caches not only make sense as separate proxy caches and caches on the server, but have proven useful especially built into the client applications (best example is the typical web browser which speeds up loading by reusing fresh objects found within its local cache).
When providing a specification for a Client API for JAX-RS, it makes very much sense to support local caching.
(a) Automatic use of local caches
Java SE since long time comes with support for local caches, but actually did never supply an implementation for one, so least people know about this feature. So without automatic use of local cache by the Client API implementation itself, the typical Client API consumer will build the cache into his application. But such a cache shouldn't be part of the application, as there is just no difference between that cache and any other cache for any other Client API based applilcation.
So it makes pretty sense that the Client API provides features to enable or disable local caching and then make use of local caches itself, without further caches coded into the surrounding application.
As a client's source code shall not be dependent of any particular implementation of the Client API, the API for configuring the cache must be part of the JAX-RS specification.
(b) Answering conditional requests using local caches
The Client API is expected to support conditional requests. It makes sense that before sending the request the local cache is checked whether it contains a fresh object fulfilling the request (e. g. when having asked for a resource before and now asking for a fragment of it, or when polling frequently for the same resource but the resource was configured by the server to stay fresh for rather long time).
As a client programmer likes to guarantee how his application works (i. e. whether it does local caching or not), it must be clearly specified by the JAX-RS specification, that an implementation must resolve conditional requests first using local caches, as soon as local caches are enabled by the client program using the JAX-RS Client API.
[2.0]
UriBuilder needs a fromTemplate(String template). I'm doing some HATEOAS and
want to pass around a full uri template with host, port, and embedded template
parameters.
For example, a Link header with a template link. I want to create a UriBuilder
from the opaque string and fill in the template parameters.
Link: <http://foo.com/orders/
{id}
; rel="order"
Currently UriBuilder only has a fromUri(String) method which requires a valid
URI and does not allow template parameters.
Operating System: All
Platform: Macintosh
Transferring from Jersey issue JERSEY-410
The Javadoc on Request.evaluatePreconditions() [1] implies the ETag will be set
on any non-null builder. This is not the case for a response of 412 Precondition
Failed. The ETag is optional in the case of a 304 Not Modified response. The
pertinent part of the HTTP 1.1 spec starts at the If-Match section [2].
[1] https://jsr311.dev.java.net/nonav/releases/1.0/javax/ws/rs/core/Request.html
[2] http://greenbytes.de/tech/webdav/rfc2616.html#header.if-match
Operating System: All
Platform: All
Maven2 more and more gets popular these days.
A lot of java.net projects actually are available in Maven2 repositories. While
most of them are found in java.net's repository, many are found in the so-
called "central" Maven2 repository. Few are found in both, increasing "high"
availability in case of repository faults.
Unfortunately least projects on java.net so far have published any reliable,
public information about the frequently filled repositories (possibly lots of
repos, for redundancy and for separation of stable releases and SNAPSHOTs), or
the dependency information needed to put in the user's pom.xml. Also, often the
information, to which version to link to is incorrect. Many projects publish
information that people have to link to x, but that is
wrong, since it is just a proposal to Maven2 to use x, not a hard link. If
users are forced to do hard links on exactly this version, [x]
must get used instead. But best it would be to declare that Maven2
shall be free to chose any bug fix release within a given range on its own,
using (depending on the version name schema of the particular project)
[2.0,3.0) what means that any version is ok to use, starting with 2.0
(included), ending with 3.0 (excluded, due to possibly changed API changing
backwards compatibility).
That makes using the project more costly than needed.
So I want to please you to add a clear and up-to-date and unambiguous
information (best: on the main index.html) which repositories to configure and
what dependencies to set. As an example how this could (or should?) look like,
please check https://webdav.dev.java.net/index.html#downloads .
All Maven2 users will be very happy to find this information kept up-to-date.
One last note: Maven2 typically uses distinct repositories for SNAPSHOTs
("nightly builds") and stable releases. It is essential for stable use of
Maven2 to really use distinct repositories. Otherwise it will happen that
2.0,3.0) links to 3.0-SNAPSHOT, since that is a release
before 3.0. As a result, dependent projects won't compile anymore, due to
possible API changes. The only way (and the way Maven2 wants people to work
like) is to keep SNAPSHOTs in a separate repositoriy, so dependend projects
looking up new bug fixes will not take nightly builds into account. I already
filed a request to open a SNAPSHOT repo on java.net with the issue tracker of
the java.net admins.
Operating System: All
Platform: All
Need a way to appropriately escape URI components that contain legitimate {} so they are not treated as
URI template parameters. One possibility would be to add a static method to perform such encoding.
See also: http://java.net/jira/browse/jersey-232
Operating System: All
Platform: Macintosh
How should Request#selectVariant behave if no variant matches at all?
Operating System: All
Platform: All
Hi, quite often I wish for an extra constructor for the WebApplicationException
to quickly generate an errormessage. Mainly I would like to do:
throw new WebApplicationException("You should have set the foo param", 400);
But I guess instead of just accepting strings, allowing any Entity would be a
nice bonus.
I know I can do this by creating a Response etc, but that taxes my muscle
memory, and IMHO this is an easy enhancement to make.
Hope you see the value in it
Operating System: All
Platform: All
As per the current spec trailing slashes are ignored for the selection of root
resources and resource methods.
This is odd, because it gives effectively two names to the HTTP-resources made
available but it also has a significant practical disadvantage: A resource
method that generates relative links has to have the UriInfo injected and check
for the presence/absence of trailing slash and either adapt the relative links
or send a redirect. It would be good if implementations would free applications
from this burden.
See also: mail-thread from 2009-01-06 on [email protected] "trailing slash"
Operating System: All
Platform: All
[2.1]
Transmission of XML is quite a burden for the net due to a lot of formatting and readability information. Due to that, several proposals had been created, like Fast Infoset. It makes sense to support such transport encodings. As client and server only rely on the transported encoding, it is necessary to contain the used encoding in the specification of the service. As the service is implemented using JAX-RS with transparency to the underlying levels like Servlets or Containers, JAX-RS must contain a possibility to define the encoding supported by the service (otherwise the service implementation would become dependent of specific Servlets or Containers).
I want to propose a minimum set of encodings:
(Mandatory) EXI - http://www.w3.org/TR/2011/PR-exi-20110120/
(Optional but mentioned) Fast Infoset
[2.0]
As described in the JAX-RS 2.0 JSR (http://jcp.org/en/jsr/proposalDetails?id=339)::)
The most commonly requested feature for JAX-RS 2.0 is a client API: many if not all JAX-RS implementations provide some degree of client API support. This JSR will define two client APIs, both compatible with the REST style: a low level API using a builder pattern and a higher level one leveraging the former. Common security mechanisms will also be specified. The API will not define how HTTP client implementations, such as HttpUrlConnection or the Apache HTTP client library, will plug into the API. The API will support synchronous and asynchronous response processing. WebSocket or HTTP streaming processing of responses are out of scope for this JSR and will be handled in a future revision of JAX-RS.
This issue only covers the low-level client API.
This issue is copied from JERSEY-318
For a lot of purposes it is really important to be able to set the charset. The
current implementation leaves no room for that. Sure I can do
return Response.ok(resultList).header("Content-Type", "application/json;
charset=UTF-8").build();
But what good is that if I need multiple output formats besides json? The
standard:
return Response.ok(resultList).type(MediaType.APPLICATION_ATOM_XML).build();
leaves no room for this.
Operating System: All
Platform: Macintosh
JSR339 will provide a Client API and will target inclusion into Java EE 7. Java EE defines a client container. For EJB it defines the use of JAAS, so a client GUI could show a dialog asking for a password when asked by JAAS to do that, then the ACC forwards the credentials to the server with any further EJB invocation. For JAX-RS clients running inside the ACC the same must be possible, i. e. as a reaction to WWW-Authenticate the JAX-RS client must trigger JAAS which in turn asks the provided callback handler to show the login dialog or to return the stored credentials, and then must send the same request again with Authorization: header. It must not be the client application's job to configure the Client API to do so, just as it is not it's job with EJB currently. Again, this feature is only requested for applications running inside of the Java EE Application Client Container. Thus, the JSR339 specification must add a chapter about the deployment target "Java EE Application Client Container" in parallel to the existing target "Java EE" which currently only talks about the server side.
[2.0]
Bill Burke writes:
The spec says: "If an ExceptionMapper for EJBException or subclass is not
included with an appliction, then exceptions thrown by an EJB resource class or
provider method MUST be treated as an EJB application exception..."
An "application exception" in EJB means that the thrown exception will not
automatically cause a rollback and should be propagated as-is. Following this
JAX-RS/EJBException logic to the letter of the law would make it impossible for
EJB applications to throw exceptions that cause transaction rollbacks.
The EJB container wraps unchecked (non applicaton) exceptions within
EJBException. Unchecked exceptions are required by the EJB specification to
trigger a rollback unless they are annotated with @applicationexception or
ejb-jar.xml equivalent.
The spec should instead just say:
"If an ExceptionMapper for EJBException or subclass is not included with an
appliction, then EJBException thrown by an EJB resource class or provider method
MUST be unwrapped and processed as described in section 3.3.4"
Operating System: All
Platform: Macintosh
As discussed in this thread, ideally Response/ResponseBuilder would be generic
to better support static discovery of types for WADL.
A couple of methods were discussed. Paul Sandoz's original proposal made use of
the . notation:
public class Main {
public static class Response<T> {
private final T entity;
private Response(T entity) {
this.entity = entity;
}
public T getEntity() {
return entity;
}
public static class ResponseBuilder<T> {
private T entity;
public ResponseBuilder<T> entity(T entity) {
this.entity = entity;
return this;
}
public Response<T> build() {
return new Response<T>(entity);
}
static protected <T> ResponseBuilder<T> newInstance() {
return RuntimeDelegate.getInstance().<T>createResponseBuilder();
}
}
static public <T> ResponseBuilder<T> start() {
return new ResponseBuilder<T>();
}
}
public static class RuntimeDelegate {
public static RuntimeDelegate getInstance() {
return new RuntimeDelegate();
}
public <T> Response.ResponseBuilder<T> createResponseBuilder() {
return new Response.ResponseBuilder<T>();
}
}
/**
* @param args the command line arguments
*/
public static void main(String[] args) {
Response<String> r = Response.<String>start().entity("xx").build();
String e = r.getEntity();
System.out.println(e);
}
}
And then I put forward a modified version that removed the need for using the
. notation by creating a new interim typed version of the Builder:
// Generified Response public class Response<T> {
static class GListString extends GenericEntity<List<String>> {
public GListString(List<String> list) {
super(list);
}
}
private final T entity;
private Response(T entity) {
this.entity = entity;
}
public T getEntity() {
return entity;
}
public static <T> ResponseBuilder<T> start() {
return new ResponseBuilder<T>("Some State");
}
public static class ResponseBuilder<T> {
private Object state;
private Type type;
private T entity;
public ResponseBuilder(Object state) {
this.state = state;
}
public ResponseBuilder(Object state, Type type, T object) {
this(state);
this.type = type;
this.entity = object;
}
public ResponseBuilder<T> header(String name, String value) {
return this;
}
public <T, K extends GenericEntity<T>> ResponseBuilder<T> entity(K ent) {
return new ResponseBuilder<T>(state, ent.getType(), ent.getEntity());
}
public <T> ResponseBuilder<T> entity(T ent) {
return new ResponseBuilder<T>(state, ent.getClass(), ent);
}
public Response<T> build() {
return new Response<T>(entity);
}
}
public static void main(String[] args) {
List<String> list = new ArrayList<String>();
GListString genericList =
new GListString(list);
Response<List<String>> response = Response
.start()
.header("Content-Type", "fudge")
.entity(list)
.build();
// Using generic entity
//
Response<List<String>> genericResponse = Response
.start()
.header("Content-Type", "fudge")
.entity(genericList)
.build();
// String example
//
Response<String> stringResponse = Response
.start() // ResponseBuilder<?>
.entity("String") // ResponseBuilder<String>
.header("Content-Type", "cheese") // ResponseBuilder<String>
.build();
}
}
It is possible that neither solution is correct; but it would be good to look
for a modification that covers some of the ideas in the 2.x spec release.
Operating System: All
Platform: All
URL: http://n2.nabble.com/xml-schema-in-request-and-response-wadl-td3943317.html#a3943317
[2.1]
Need to specify the behavior in section 3.3.3 when an instance of an anonymous subclass is used as a
returned entity. One idea is to use the superclass instead of the anonymous class.
Operating System: All
Platform: Macintosh
The JSR 311 RI "Jersey" contains a nice feature which deals with empy bodies:
The com.sun.jersey.core.provider.EntityHolder type may be utilized as a
"meta-entity" to determine whether a request consumed by the server, or a
response consumed by the client, contains the entity or contains no entity,
for example:
@post
@consumes("text/plain")
public void post(EntityHolder s) {
if (s.hasEntity())
{ MyJAXBObject entity = s.getEntity(); }
else
{ ... }
}
As in several cases, e. g. in some WebDAV implementations, it is needed to deal
with empty bodies, it would be great if a future JAX-RS revision would contain
EntityHolder as a mandatory element.
This also would be a good solution for the problem describes in issue #55
(http://java.net/jira/browse/JSR311-55), which was proposed by
Paul SANDOZ in this comment: http://java.net/jira/browse/JERSEY-154
Operating System: All
Platform: All
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.