> 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.
So that would be *your* custom router. Mine could be different. But by
exposing the model, anyone would be able to do it the way they feel
more productive for themselves. The way the configuration is done
nowadays, its imposed as annotations+strings.
> 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.
Same thing here. My custom router would take care of it, no one would
ever break.
We have been doing this for more than an year, allowing annotation
config, programmatic config, conventions and convention configuration
(and even xml config if someone wants)... no compatibility was ever
broken and anyone is free to make the framework work with the code
they want to write, instead of making the code the framework wants
them to make.
Again, no compatibility breaks.
I don't know if you agreed by the refactoring though. That string and
annotations refactoring does not exist in IDE's, where as code
refactoring exists.
Guilherme Silveira
Caelum | Ensino e Inovação
http://www.caelum.com.br/
> 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
>