On 11.03.2011, at 14:03, Bill Burke wrote:
> -1, implied rules like this are unintuitive and can break clients easy when you refactor code by accident. I was against this in JAX-RS 1.0:
Yes, but this is also true for JPA 1.0+. If you change the name of the class, it will no more match the table, and if you change the name of the field - the corresponding column.
I actually meant:
@GET
@Path("orders")
public String orders()
=
@GET
@Path
public String orders()
Deriving the HTTP - methods from the method name prefix is an interesting idea...
public
>
> @Path
> public String get()
>
> Where @GET was implied by the method prefix name "get". Sometimes a tiny bit more verbosity goes a long way to help new code maintainers understand what is going on (or help you remember what you did).
>
> I do wish though that @Path's value() was a default of "" or "/".
>
> On 3/11/11 2:49 AM, Adam Bien wrote:
>> Hi Guilherme,
>>
>> you mean:
>>
>>>>> @Path("something")
>>>>> @GET
>>>>> public Response something(...
>>>>>
>>>>> @Path("something")
>>>>> class SomethingResource {
>>>>> }
>>
>> should be
>>
>>
>> @Path
>> public Response something
>>
>> and
>>
>> @Path
>> class SomethingResource ?
>>
>>
>> Then +1. I get questions in every workshop, why we have to specify that redundantly. We cannot go to far, because a JAX-Resource can be also an EJB or managed bean at the same time.
>>
>> In general - we should minimize the total amount of required annotations.
>>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com