| All,
I tend to agree with Christian. This has come up before in earlier discussions. Although I can see how it _could_ be practical in some cases, even some of those are questionable. Most standard verb combinations make little sense, especially those that combine entity vs. entity-less requests.
Even the @POST/@PUT is arguably incorrect given that @PUT is intended to be idempotent and @POST is not, so they really ought to match different resource methods (and possibly shared logic via helpers, private methods, etc.).
— Santiago
I have a slightly different position. I also do not see much sense in mapping multiple http verbs onto the same Java method, and in case I would need it, I would simply install a pre-matching filter to rewrite the verb on the fly. But on the other hand, it will not do any harm to code such "strange" mppings, and it is not restricted so far by the spec. We should not restrict it now synthetically unless there is at least one existing JAX-RS implementation that enforces us to do so. JAX-RS should only clarify how it works right now, it should not reduce the existing possibilities. It is not up to a Java specification to push people into a specific style of programming, the weird it might be. Besides that, even the JAX-RS spec already does double-mapping in at least one case by itself: HEAD and GET! So there is at least one case where the spec even enforces double mapping. As http is an open protocol one could add experimental verbs, and one could imply that those MUST be mapped to existing verbs. So it would be just fair to support this. -Markus Hi Andy, thanks for bringing this up. To be honest, I don't like the idea of allowing different HTTP method annotations on a single resource method. Especially because it would allow weird combinations like @GET & @POST which doesn't make much sense. However, I agree that clarifying that such combinations aren't allowed would be a good thing. Hi All, We had an internal customer ask whether it was allowed to use multiple method annotations on the same resource method - for example: public class MyResource { public Response postOrPut(...) {...} I couldn't find anywhere in the spec where this was explicitly allowed or forbidden. I'd be interested in hearing thoughts on whether this should be allowed or not. I'm mostly on the fence, but leaning toward not allowing it, but I can see it's usefulness. In either case, I think it would be good to document it to avoid ambiguity and potential portability issues.
--
|
