Hello *,
FWIW, here's my take on the annotation CoC topic so far:
- Resource method annotations (@GET, @POST ...) cannot be made optional unless we decide to severely break BW
compatibility with JAX-RS 1.x spec. Also, other than reducing the amount of code in the most simple cases, I do not
really see the more significant benefit of such change. Thus it seems to me, the cost/value ratio in this case is too
high. I would not support this change.
- As for @Path annotation, I would not want to make it optional either, because I am concerned about the readability and
maintainability of the code below due to the potential side effects[1]. To workaround the mainainability issues, we
would need to specify a lots of rules, which IMHO compromises the main reason of CoC as it violates the KISS principle.
- As for specifying the default value of the @Path annotation, I can see certain limited benefit in the early
prototyping phase of a project. And since it is not breaking BW compatibility, I'd be willing to consider a proposal
that would be aligned with principles stated in JSR250. Being the part of the same umbrella specification, we should
converge with related specifications rather than diverge from them.
Obviously, as demonstrated by the code below, there is a plenty of space in implementations for adding lots of
additional flexibility dimensions. I am not sure however that we should be bringing all those dimensions into the spec.
Also, it seems questionable how the code below actually benefits the CoC. How do you know that this class is actually a
root resource? Obviously, you need to configure it somewhere somehow either in a deployment descriptor or programmatically.
Kind regards,
Marek
[1] In JAX-WS where @WebMethod (specified in JSR-181) is optional, this optionality is causing frequent issues on the
customer side. If someone adds a new annotated method to a WS interface or tries to customize a SOAP signature on just a
single method, suddenly all existing not annotated web service methods from the WS interface.
On 03/16/2011 09:17 PM, Guilherme Silveira wrote:
> public class FooResource {
>
> @GET String customer()
>
> }
>
> This is what we support today... that's why I am proposing all those interfaces.