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.
--
Francesco Chicchiriccò
Tirasa - Open Source Excellence
http://www.tirasa.net/
Involved at The Apache Software Foundation:
member, Syncope PMC chair, Cocoon PMC, Olingo PMC
http://people.apache.org/~ilgrosso/
