On 3/11/11 8:31 AM, Guilherme Silveira wrote:
>> -1, implied rules like this are unintuitive
> The advantage of exposing the semantic model of your domain is that
> anyone can built those defaults the way they want, without breaking
> the spec. So if JAX-RS provides a model where I can do:
>
> routes.add(new CustomRouteHandler());
>
> The team can provide its custom route handlers (or jar'ed ones), such as:
>
> public boolean canHandler(URI uri) {
> return true based on some default;
> }
>
> It's a matter of exposing your model, instead of forcing specific
> configuration approaches. Then, each one can decide on its own what is
> best and still be compatible.
>
>> and can break clients easy when
>> you refactor code by accident.
> On the contrary, not being DRY is the root of refactor problems. What
> happens nowadays if you change the annotation path and don't change
> all the URIBuilders (which are not DRY, non conventioned)? It breaks.
> If conventions and DRY where followed, nothing would.
>
> Repetition by annotation and strings, is the root of breaking things
> after refactoring. Those are the structures that refactor in eclipse
> and other IDEs will not understand... thats the problem with
> annotation and string based programming.
>
How would you tell the difference between a sub resource locator and a
@GET request if the HTTP method was determined by the method signature?
I know I use getXXX() method signature names for some of my resource
locator methods. I'm sure others do as well.
Also, if you were implicitly building URI mappings, how would you tell
the different between an empty path "" and whether or not you wanted an
implicit mapping. Define new annotations? -1.
Again, I know this point has been argued/discuessed in JAX-RS 1.0.
Don't understand why we would need to bring it up again. I think adding
any of this would greatly increase the risk of breaking existing
applications.
On the topic of reducing annotations, I wanted something like this in
JAX-RS 1.0:
@GET("/some/path")
@POST("/some/path")
This would allow you to get rid of the need for @Path on methods. It
could be added and not break backward compatibility.
I also thought @Path was way too overloaded in JAX-RS. It would have
been better to have a @RootResource annotation and a @ResourceLocator
annotation rather than reusing @Path everywhere for everything:
i.e.
@RootResource("/bills")
public class MyBillingService
{
@ResourceLocator("customers")
public Customers getCustomers() {...}
@GET("{id}")
public String getBill(...) {...}
}
Too late for this though...
Bill
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com