It’s probably not so much a bug as a limitation of the Servlet spec. The details of how a JAX-RS @ApplicationPath is handled is implementation specific, and I can’t speak for all implementations, but I’d guess the typical approach is to simply use it as a servlet URL pattern. Taking a look at Jersey’s ServletContainerInitializer … Read more
You can create filters and easily bind them to the endpoints you need to log, keeping your endpoints lean and focused on the business logic. Defining a name binding annotation To bind filters to your REST endpoints, JAX-RS provides the meta-annotation @NameBinding and it can be used as following: @NameBinding @Retention(RUNTIME) @Target({TYPE, METHOD}) public @interface … Read more
You don’t need HttpServletResponse to set a header on the response. You can do it using javax.ws.rs.core.Response. Just make your method to return Response instead of entity: return Response.ok(entity).header(“Content-Disposition”, “attachment; filename=\”” + fileName + “\””).build() If you still want to use HttpServletResponse you can get it either injected to one of the class fields, or … Read more
@Path(“/{a:path1|path2}”) From resteasy docs: http://docs.jboss.org/resteasy/docs/1.0.2.GA/userguide/html_single/index.html#_Path_and_regular_expression_mappings
In Jersey 2.0, you’ll want to use BeanParam to seamlessly provide what you’re looking for in the normal Jersey style. From the above linked doc page, you can use BeanParam to do something like: @GET @Path(“find”) @Produces(MediaType.APPLICATION_XML) public FindResponse find(@BeanParam ParameterBean paramBean) { String prop1 = paramBean.prop1; String prop2 = paramBean.prop2; String prop3 = paramBean.prop3; … Read more
I finally found my answer. I added <dependency> <groupId>com.sun.jersey</groupId> <artifactId>jersey-json</artifactId> <version>1.8</version> </dependency> to my pom.xml file. Then I added <init-param> <param-name>com.sun.jersey.api.json.POJOMappingFeature</param-name> <param-value>true</param-value> </init-param> to my web.xml file, and everything works fine. No change was required to my code above.
Good question. Unfortunately (or maybe fortunately) there is no mechanism in JAX-RS to make any params mandatory. If a parameter is not supplied it’s value will be NULL and your resource should deal with it accordingly. I would recommend to use WebApplicationException to inform your users: @GET @Path(“/some-path”) public String read(@QueryParam(“name”) String name) { if … Read more
Providers are a simply a way of extending and customizing the JAX-RS runtime. You can think of them as plugins that (potentially) alter the behavior of the runtime, in order to accomplish a set of (program defined) goals. Providers are not the same as resources classes, they exist, conceptually, at a level in-between resources classes … Read more
In my experience, GET /users/{id} GET /users/email/{email} is the most common approach. I would also expect the methods to return a 404 Not Found if a user doesn’t exist with the provided id or email. I wouldn’t be surprised to see GET /users/id/{id}, either (though in my opinion, it is redundant). Comments on the other … Read more
Okay, I could fix it by searching the samples This does work, but it can only be used for JSON and not for XML @GET @Produces({MediaType.APPLICATION_JSON}) @Path(“/get”) public JSONArray get() {; return new JSONArray(dao.getStringList()); } Fixes problem, but is there also a generic approach?