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 From: jaxrs-dev-bounces@xxxxxxxxxxx [mailto:jaxrs-dev-bounces@xxxxxxxxxxx] On Behalf Of Christian Kaltepoth
Sent: Samstag, 10. März 2018 09:43
To: jaxrs developer discussions
Subject: Re: [jaxrs-dev] Allow multiple HTTP method annotations on the same resource method? 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. _______________________________________________
jaxrs-dev mailing list
jaxrs-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jaxrs-dev
-- |
