2012-06-21 4 views
7

Tengo una clase este se anota con @Path así:Jersey @Path para los sustantivos plurales/REST individuales en una misma clase

@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 
    //...} 

Cuando el fuego de un cliente de prueba del localhost/mapas de widgets como se esperaba, pero cuando el método getWidgetById está mapeado a localhost/widgets/widget/{id}. Esto no es lo que quiero - me gustaría tener localhost/widgets and localhost/widget/{id}

He tratado de omitir la anotación @Path a nivel de clase, pero que impide Jersey del reconocimiento de esta clase como un recurso REST (He intentado tanto la ScanningResourceConfig y la ClassNameResourceConfig - Ninguno ha podido cargar la clase como recurso a menos que hubiera un @Path en el nivel de clase.

Supongo que una solución (fea) sería dividir los métodos entre clases en una clase WidgetResource y una clase WidgetsResource. Creo que esta es una solución terrible ya que ambos métodos comparten recursos en la misma clase, pero realmente necesito el REST-ful localhost/widget (para una sola entidad) y localhost/widgets (para el plural).

Me falta algo - ¿hay alguna manera para que Jersey tome la clase como una clase de Recursos si solo @Path anota los métodos (no pude hacerlo funcionar), si no puedo forzar absoluto mapeo (@Path(/widget/{id})) o algún mapeo relativo (@Path(../widget/id) ninguno de los dos funciona en la realidad, solo una analogía de lo que busco. ¡Gracias!

Respuesta

8

Esta parte es sobre lo que necesidad:

Personalmente, creo que el mapeo extraño y confuso. Sólo mantenerlo así:

@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 
    //... 
    } 
} 

Parece natural para anexar la ruta a una colección con un ID a buscar un objeto de la colección. Realmente no hay necesidad de hacerlo widgets/widget/{id}. La parte widget es obvia e innecesaria.

Aquí hay un tutorial muy bueno sobre API RESTful: "Teach a dog to REST" by apigee Creo que es un video realmente bueno. Los autores hacen un par de buenos comentarios.Y aquí hay un enlace a una longer version of the same presentation


Esta parte es sobre lo que desea:

Si realmente quiere mantener el dualismo plural/singular (que realmente no recomiendo) , puede anotar el código de la siguiente manera: Pero es realmente feo

@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 
    //... 
    } 
} 
+0

Creo que tengo el widget/widgets del video, pero parece que podría estar recordando mal, en cualquier caso es parte de nuestra API, pero podemos cambiarlo si hay un buen caso. Voy a consultar con el equipo e ir con uno de los enfoques anteriores. ¡Gracias! – cschooley

+1

@cschooley eso es gracioso, no recuerdo nada como esto. Supongo que lo veré nuevamente. – toniedzwiedz

+0

Diseñamos nuestra API para tener un par plural singular de URL como esta (esta es la versión larga) (las cosas en plural comienzan a las 11:00): http://blog.apigee.com/detail/slides_for_restful_api_design_second_edition_webinar – cschooley

2

Mi sugerencia es que sus rutas sean: "widgets" y "widgets/id/{id}". O si sabía que nunca iba a consultar por otra cosa que no fuera identificación, su segunda podría ser simplemente "widgets/{id}".

No cambiaría entre plural y singular en su camino. Como tiene acceso al mismo tipo de recurso para ambos, su raíz debe ser la misma. La segunda forma simplemente lo especifica más: un enfoque basado en vectorización para ser más específico.

Cuestiones relacionadas