Hi Florian, Adding my 2 cents, I might not be able to completely answer your question.
1. Have a look at second answer (with higher upvotes) at http://stackoverflow.com/questions/31301680/can-i-have-the-same-path-for-two-classes-in-rest-api JSR for JAX-RS, has the legitimate use cases where multiple Resorces can point to same URI but matched against different Request headers etc. 2. My suggestion would be to follow some kind of defined patterns (using Sub-Resourses) that actually make up the URI, instead of Fixing the URI for each resource. Once you have such a formal pattern, you should not face the conflicts at all (or catch them way early in CRs) On Monday, February 13, 2017 at 2:05:34 PM UTC+5:30, Florian Friemel wrote: > > It's possible to register multiple resources that have the same path. > However, only one of them will actually be exposed through the API. > > Example: In the dropwizard example project > <https://github.com/dropwizard/dropwizard/tree/master/dropwizard-example>, > ProtectedResource and ProtectedClassResource share the same paths. > Currently, only ProtectedResource is registered in > HelloWorldApplication::run. When ProtectedClassResource is registered as > well, DropwizardResourceConfig will tell you that these paths were > configured: > > GET /protected (com.example.helloworld.resources.ProtectedResource) > GET /protected/admin > (com.example.helloworld.resources.ProtectedResource) > GET /protected/guest > (com.example.helloworld.resources.ProtectedClassResource) > > In larger projects, it's easy to accidentally define a resource with a > path that is already taken by another resource. Of course this kind of > error can be avoided with integration tests (at least to some degree). > However, it would be nice to have a validator that complains about such > conflicts at compile time. I'm guessing that such a validator already > exists, so maybe you can point me in the right direction? > > I added integration tests that exemplify this problem to the example > application > <https://github.com/florian-f/dropwizard/blob/master/dropwizard-example/src/test/java/com/example/helloworld/IntegrationTest.java>. > > Another issue that I noticed while doing so is that even though /protected > is supposedly associated with ProtectedResource, the corresponding > IntegrationTest::testProtectedEndpoint fails - and debugging with a > breakpoint in ProtectedResource::showSecret revealed that the method is > never called. Instead, ProtectedClassResource::showSecret is called, > despite DropwizardResourceConfig telling you otherwise. I'm not sure if > this is a bug or if I missed something, so it would be nice if someone else > could weigh in on this. > > Best, > Florian > > > > > -- You received this message because you are subscribed to the Google Groups "dropwizard-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
