Jersey @Path dla liczby mnogiej rzeczowników/Single Spoczywaj w tej samej klasie

Question

Mam klasy, to jest opatrzone @Path tak:

@Path("widgets") 
@Produces(MediaType.APPLICATION_XML) 
public class WidgetResource { 

    @GET 
    public Response getWidgets(@QueryParam("limit")) 
    { 
    //This class returns the plural noun, a list of widgets 
    //...} 

@GET 
@Path("widget/{id}") 
    public Response getWidgetById(@PathParam("id") long id) 
    { 
    //This class returns a single widget by id 
    //...} 

Kiedy odpalić klienta testowego localhost/widgety mapy zgodnie z oczekiwaniami, ale gdy metoda getWidgetById jest odwzorowana na localhost/widgets/widget/{id}. To nie jest to, co chcę - chciałabym mieć localhost/widgets and localhost/widget/{id}

Próbowałem pomijając adnotacji na poziomie klasy @Path, ale zapobiega Jersey od rozpoznawania tej klasy jako REST Zasobu (próbowałem zarówno ScanningResourceConfig i ClassNameResourceConfig - nie udało się załadować klasy jako zasobu, chyba że na poziomie klasy było @Path).

Myślę, że (brzydkie) obejście byłoby podzielenie metod między klasami WidgetResource klasy i WidgetsResource klasy. Myślę, że to straszne rozwiązanie, ponieważ obie te metody dzielą zasoby w tej samej klasie, ale naprawdę potrzebuję REST-ful localhost/widget (dla pojedynczego obiektu) i localhost/widgets (dla liczby mnogiej).

Czy brakuje mi czegoś - czy jest jakiś sposób dla mnie, aby Jersey odebrał klasę jako klasę zasobów, jeśli tylko przytoczę metody (nie mogłem jej uruchomić), jeśli nie, mogę wymusić absolutną mapowanie (@Path(/widget/{id})) lub mapowanie względne (@Path(../widget/id) - żadna z nich nie działa w rzeczywistości - tylko analogia tego, do czego dążę. Dzięki!

Answer 1

Ta część jest o tym, co potrzeba:

Osobiście uważam, że Twój mapowanie dziwne i mylące. Po prostu tak:

@Path("widgets") 
@Produces(MediaType.APPLICATION_XML) 
public class WidgetResource { 

    @GET 
    public Response getWidgets(@QueryParam("limit")) { 
    //This method returns the plural noun, a list of widgets 
    // it's also possible to limit the number returned by 
    // using a query parameter. You could easily implement 
    // pagination by adding further query parameters like 
    // 'offset', 'sortOrder', etc. 
    //... 
    } 

    @GET 
    @Path("{id}") 
    public Response getWidgetById(@PathParam("id") long id) { 
    //This method returns a single widget by id 
    //... 
    } 
} 

Naturalne wydaje się dołączenie ścieżki do kolekcji z identyfikatorem w celu pobrania obiektu z kolekcji. Naprawdę nie ma potrzeby, aby to zrobić widgets/widget/{id}. Część widget jest oczywista i niepotrzebna.

Oto naprawdę fajny samouczek dotyczący interfejsów API RESTful: "Teach a dog to REST" by apigee Myślę, że to naprawdę dobry film. Autorzy robią kilka dobrych punktów.A oto link do longer version of the same presentation

---

ta część jest o co chcą:

Jeśli naprawdę chcesz zachować mnogą/pojedyncza dualizm (który tak naprawdę nie polecam) można opisywać swój kod tak: Ale to naprawdę brzydki

@Path("/") 
@Produces(MediaType.APPLICATION_XML) 
public class WidgetResource { 

    @GET 
    @Path("widgets") 
    public Response getWidgets(@QueryParam("limit")) { 
    //This method returns the plural noun, a list of widgets 
    //...} 

    @GET 
    @Path("widget/{id}") 
    public Response getWidgetById(@PathParam("id") long id) { 
    //This method returns a single widget by id 
    //... 
    } 
} 

Answer 2

Moja sugestia dotyczy ścieżek: "widgets" i "widgets/id/{id}". Lub jeśli wiesz, że nigdy nie będziesz pytać o nic poza identyfikatorem, twój drugi może po prostu być "widgets/{id}".

Nie przełączałbym się między liczbą mnogą a liczbą pojedynczą na twojej ścieżce. Ponieważ dostęp do tego samego rodzaju zasobów dla obu, twój root powinien być taki sam. Druga forma precyzuje to bardziej - oparte na wektorowaniu podejście do uzyskiwania bardziej szczegółowych informacji.