通过查询参数选择Jersey方法 [英] Jersey method selection by query parameters
问题描述
我需要实现一个使用第一个查询参数来识别操作的web服务，即客户端调用类似于： http：// localhost：8080 / ws / operation？info 或 http：// localhost：8080 / ws / operation？create& name = something 。
I need to implement a webservice that uses the first query parameter to identify the operation, i.e. the client call would be something like: http://localhost:8080/ws/operation?info or http://localhost:8080/ws/operation?create&name=something.
似乎我无法区分使用@Path注释的方法，因为区别特征在于查询参数。以下示例也是抛出异常：
It seems that I cannot distinguish the methods using the @Path annotation as the distinguishing characteristic is in the query parameters. And the following example is throwing exceptions as well:
package com.example.ws;
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.QueryParam;
@Path("/operation")
public class Operation {
@GET
public String info(@QueryParam("info") String info) {
return "info";
}
@GET
public String create(@QueryParam("create") String create) {
return "create";
}
}
有没有办法指定要使用的方法，具体取决于在查询参数？或者我真的必须定义一个方法并在那个方法中检查是否设置了某些查询参数？
Is there a way to specify methods to be used depending on query parameters? Or do I really have to define one method and check within that one whether certain query parameters are set?
推荐答案
我认为Claudio是正确 - 您可以使用Jersey，但是您可以自己处理查询参数，因为它只匹配路径。
I think Claudio is correct - you could use Jersey, but you'd be on your own to handle the query parameters since it only matches on the path.
您可以注入UriInfo并拉查询参数：
You could inject a UriInfo and pull the query parameters out of that:
@Path("/operation")
public class Operation {
@Context
protected UriInfo info;
@GET
public String operation() {
if (info.getQueryParameters().containsKey("create"))
// do stuff
else if (info.getQueryParameters().containsKey("info"))
// other stuff
}
}
您可以从Jersey切换到另一个框架。我相信Spring 可以根据查询参数路由到多个方法。
You could switch from Jersey to another framework. I believe that Spring can route to multiple methods based on query parameters.
正如你所提到的，也许你可以写一些更标准的东西然后重新映射要求。例如，您可以使用Servlet过滤器或前端服务器，如 Apache httpd 或nginx修改请求。
As you mentioned, perhaps you could write something that is a bit more standard and then remap the requests to that. For example, you could use a Servlet filter or a front end server like Apache httpd or nginx to modify the request.
考虑资源这些行动的作用是什么？客户账户，电影，股票交易等。为了论证，让我们说它是Foo。你可能会这样：
Thinking in terms of resources what is it that these operations are acting on? Customer accounts, movies, stock trades, etc. For arguments sake, let's say it's "Foo". You might go with something like this:
@Path("/foo")
public class FooResource {
@Context
protected UriInfo info;
@GET
@Produces({MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON})
public Foo getById(@QueryParam("id") int id) {
// get Foo by id
Foo = ....
// return an instance of Foo and let Jersey convert it to XML
// or JSON depending on the "Accept" header that the client sent
return foo;
}
@POST
@Consumes({MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON})
public Response create(Foo instance)
{
// let Jersey deserialize the request body from JSON or XML.
// save the instance however you want
int id = fooService.save(instance);
// return a 204 "created" with a "Location" header
URI location = info.getAbsolutePathBuilder().path("{id}").build(id);
return Response.created(location).build();
}
}
听起来你的URI结构是由其他人强制执行的，所以这可能不适合你。如果你继续使用当前的URI结构，那么你应该注意一个主要的缺陷。
It sounds like your URI structure is mandated by someone else so this might not be an option for you. If you do proceed with the current URI structure, there's one major pitfall that you should be aware of.
根据 HTTP 1.1规范，GET请求应为幂等。您的当前设计似乎是使用GET请求创建新的服务器端实例。存在破损的可能性......中间代理或Web浏览器可以缓存对您的GET请求的响应并阻止创建新实例。
According to the HTTP 1.1 spec, GET requests should be idempotent. It appears that your current design is creating new server side instances with GET requests. There's potential for breakage... intermediate proxies or web browsers could cache responses to your GET requests and prevent new instances from being created.
这篇关于通过查询参数选择Jersey方法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
