Hi Francesco See https://issues.apache.org/jira/browse/CXF-6447,
So you'd be able to optimize the signature if still preferred, the server code would stay completely portable, though only CXF proxies would likely to work with such signatures in the short term at least
Thanks, Sergey On 08/06/15 10:43, Sergey Beryozkin wrote:
Sorry, that will not work with the proxies as they won't be able to resolve the {key} :-), with webclients only... I wonder if we can explore your idea on the client side and try to resolve a variable if the body bean is available...I'll try to experiment a bit later on Thanks, Sergey On 08/06/15 10:40, Sergey Beryozkin wrote:Hi Francesco, By the way, it is fine to have something like this: @PUT @Path("{key}") public void update(ResourceTo bean) {} That can actually be the optimal signature, if the bean contains the key then it can be taken from the bean and if not - then from UriInfo by analyzing the path value. Often a Path variable is also represented with PathParam but it is not a requirement Cheers, Sergey On 08/06/15 10:32, Francesco Chicchiriccò wrote:Hi Sergey, thanks for your response. On 08/06/2015 11:16, Sergey Beryozkin wrote:Hi Francesco Sure, you can try: @PUT @Consumes({ MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON }) void update(@NotNull ResourceTO resourceTO); Omitting the extra @Path completely and getting the key out of ResourceTo bean: PUT /resources <Resource> <key>1</key> <!- the rest of the representation --> </Resource> given that the key is available there. That said, if we were to abstract away from the the redundant proxy code where the key is specified twice during the invocation, one can say PUT targets an individual resource representation which is indeed identified as /resources/{key}. Optimizing the {key} away would lead to a slightly unbalanced space: // GET the 1st resource GET /resources/1 // Update the 1st resource PUT /resources (the representation with the key) My opinion has always been that ultimately the more practical it is the better as opposed to the purer the better. It might be reasonable to support both styles: PUT /resources/1 POST /resources as POST is usually deals with the collection of resources and I guess it may be reasonable to suggest that POSTing to a collection which already contains an element with the same key means the actual update.I'd agree to keep PUT /resources/1 which definitely makes sense; I thought there was some "magic" JAX-RS annotation to identify an argument as request body so that I could write @PUT @Path("{key}") @Consumes({ MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON }) void update(@BeanParam @RequestBody ResourceTO resourceTO); Given the considerations above, I'd say we'll probably leave things unchanged. Regards.On 08/06/15 07:05, Francesco Chicchiriccò wrote:Hi, we have several "update" methods in our JAX-RS services, with similar signature: @PUT @Path("{key}") @Consumes({ MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON }) void update(@NotNull @PathParam("key") String key, @NotNull ResourceTO resourceTO); For various reasons, the key value is already contained in the ResourceTO bean; this leads to kind of redundant invocations like as resourceService.update(resourceTO.getKey(), resourceTO); I was wondering whether this situation can be improved by using @BeanParam: void update(@BeanParam ResourceTO resourceTO); by annotating ResourceTO#setKey() with @Path("{key}"). It seems that with such setup only "key" is evaluated, e.g. the rest of ResourceTO instance is left empty. Am I missing something? Any suggestion to fix the original problem? Thanks for your support. Regards.
-- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
