Cómo heredar RequestMappings en una Spring 3 MVC REST API

Question

Estoy intentando construir una API RESTful utilizando Spring MVC. Estoy buscando un código limpio y manejable donde la estructura del paquete sigue la estructura de la url.

Así que aquí es lo que tengo:

// com.test.api.library 
@RequestMapping("/library/{libraryId}") 
public Library getLibrary(@PathVariable long libraryId) { 
    return service.getLibraryById(libraryId); 
} 

// com.test.api.library.book 
@RequestMapping("/library/{libraryId}/book/{bookId}") 
public Book getBook(@PathVariable long libraryId, @PathVariable long bookId) { 
    Library library service.getLibraryById(libraryId); 
    return library.getBookById(bookId); 
} 

Aunque esto funciona, me resulta complicado y propenso a errores que tiene que repetir "/ Library/{} libraryId "en todos los @RequestMappings heredados,/es probable que la biblioteca sea la raíz de una gran parte de la API y debe escribirse una vez y reutilizarse en lugar de estar escrita en todas partes.

me gustaría volver a escribir el libro de clase a algo como esto:

// com.test.api.library.book 
@RequestMapping("/book/{bookId}") 
public Book getBook(@PathVariable long bookId) { 
    // long libraryId magically given to me from the library-class's getLibrary() 

    Library library service.getLibraryById(libraryId); 
    return library.getBookById(bookId); 
} 

¿Hay alguna manera de primavera me puede ayudar aquí? Es aceptable para mí usar la herencia java normal, la anotación de primavera o cualquier otra cosa que me ayude a no escribir "/ library/{libraryId}" como parte de cada url que escribo.

Answer 1

No creo que sea posible. Pero puede tener la anotación @RequestMapping en la clase misma, por lo que le ahorrará al menos algo de tipeo.

Answer 2

@Controller 
@RequestMapping("/library/{libraryId}") 
public class HelloWorldController { 

    @RequestMapping(value="/book/{bookId}") 
    public ModelAndView helloWorld() { 
     .... 
    } 

} 

Answer 3

Creo que esta pregunta se ha hecho & respondieron delante: Spring MVC @RequestMapping Inheritance

Dicho esto, aquí es una manera de reducir la cantidad de información duplicada. En realidad, no hago esto en mi propio código porque creo que tener el URI justo al lado del código es más fácil de mantener, incluso si eso significa una pequeña duplicación.

@RequestMapping(URI_LIBRARY) 
public interface LibraryNamespace { 
    public static String URI_LIBRARY = "/library/{libraryId}"; 
} 

@RequestMapping(URI_BOOK) 
public interface BookNamespace { 
    public static String URI_BOOK = LibraryNamespace.URI_LIBRARY + "/book/{bookId}"; 
} 

@Controller 
public class LibraryController implements LibraryNamespace { 
    @RequestMapping("") 
    public Library get(@PathVariable long libraryId) { 
    return service.getLibraryById(libraryId); 
    } 
} 

@Controller 
public class BookController implements BookNamespace { 
    @RequestMapping("") 
    public Book get(@PathVariable long libraryId, @PathVariable long bookId) { 
    Library library service.getLibraryById(libraryId); 
    return library.getBookById(bookId); 
    } 
} 

Como yo no tomaría este enfoque yo mismo, ¡en realidad no he probado esta solución! Según mi comprensión de Spring, creo que debería funcionar ...

Answer 4

Utilice un enfoque padre polimórfico.

@Controller 
public class CommentsController { 
    @RequestMapping(value="/comments", method = RequestMethod.GET) 
    public @ResponseBody String index() { 
     /* kludge to allow optional path parameters */ 
     return index(null, null); 
    } 

    @RequestMapping(value="/{parent_collection}/{parent_id}/comments", method = RequestMethod.GET) 
    public @ResponseBody String index(@PathVariable("parent_collection") String parentCollection, @PathVariable("parent_id") String parentId) { 
     if (parentCollection == null) { 
      return "all comments"; 
     } 
     else if ((parentCollection != null) && (parentCollection.equals("posts"))) { 
      /* get parent, then get comments for parent */ 
      return "comments for single post"; 
     } 
     else if ((parentCollection != null) && (parentCollection.equals("customers"))) { 
      /* get parent, then get comments for parent */ 
      return "comments for single customer"; 
     } 
     else if ((parentCollection != null) && (parentCollection.equals("movies"))) { 
      /* get parent, then get comments for parent */ 
      return "comments for single movie"; 
     } 
    } 

    @RequestMapping(value = "/comments/{id}", method = RequestMethod.GET) 
    public @ResponseBody String show(@PathVariable Integer id) { 
     /* kludge to allow optional path parameters */ 
     return show(null, null, id); 
    } 

    @RequestMapping(value = "/{parent_collection}/{parent_id}/comments/{id}", method = RequestMethod.GET) 
    public @ResponseBody String show(@PathVariable("parent_collection") String parentCollection, @PathVariable("parent_id") String parentId, @PathVariable Integer id) { 
     /* get comment, then get parent from foreign key */ 

     if (parentCollection == null) { 
      return "single comment"; 
     } 
     else if ((parentCollection != null) && (parentCollection.equals("posts"))) { 
      return "single comment for single post"; 
     } 
     else if ((parentCollection != null) && (parentCollection.equals("customers"))) { 
      return "single comment for single customer"; 
     } 
     else if ((parentCollection != null) && (parentCollection.equals("movies"))) { 
      return "single comment for single movie"; 
     } 
    } 
} 

Además, se puede usar un controlador de base para encaminar el prefijo URI de recursos para padres (/libraries/{library_id}/../..), añadir los modelos de padres para el ámbito de la petición, y luego dejar que la solicitud se asignaciones regulares manejan el resto de la URI recursos secundarios (/../../books/1). No tengo un ejemplo de esto fuera de la mano.

Nota al margen. Los recursos anidados singulares se consideran generalmente como un antipatrón para el diseño de URI. Un controlador debe manejar sus propios recursos. Las implementaciones más comunes hacen que la clave para el recurso anidado singular sea única, es decir, no dependa de su recurso padre. Por ejemplo, una clave primaria de registro de base de datos. Sin embargo, hay situaciones en las que la clave puede no ser única, como un valor ordinal o de posición (por ejemplo, libro 1, capítulo 1, capítulo 2) o incluso una clave natural (por ejemplo, ISBN de libro, SSN de persona, dirección de correo electrónico , nombre de usuario, nombre de archivo).

Ejemplo de URIs canónicas para los recursos anidados:

• /articles => ArticlesController # índice
• /articles/1 => ArticlesController # muestran
• /articles/1/comments => CommentsController # índice
• /articles/1/comments/2 => CommentsController # mostrar (está bien, pero no es el preferido)
• /comments/2 => ComentariosController # show (preferido)