ruby on rails - tutorial - ¿Por qué tengo que trabajar más para hacer que mi aplicación Rails se ajuste a una arquitectura RESTful?

rails 5.2 api

Question

Empecé un proyecto de Rails recientemente y decidí usar controladores RESTful. Creé controladores para mis entidades clave (como Country) y agregué index , new , edit , create , show , update y delete . map.resources :country mi map.resources :country a mi archivo de rutas y la vida fue buena.

Después de que el desarrollo progresó un poco, empecé a tener problemas. A veces necesitaba acciones adicionales en mi controlador. Primero fue la acción de search que devolvió las opciones para mi elegante cuadro de búsqueda de autocompletado. Luego vino la necesidad de mostrar los países de dos maneras diferentes en diferentes lugares de la aplicación (los datos mostrados también eran diferentes, por lo que no se trataba de dos vistas). index_full acción index_full . Luego, quería mostrar un país por nombre en la URL, no por identificación, así que agregué la acción show_by_name .

¿Qué hace cuando necesita acciones más allá del index estándar, new , edit , create , show , update , delete en un controlador RESTful en Rails? ¿Debo agregar (y mantener) las rutas manuales en el archivo routes.rb (que es un problema), van en un controlador diferente, me vuelvo inseguro o me falta algo fundamental?

Supongo que estoy preguntando, ¿tengo que trabajar más y agregar acciones en mi archivo routes.rb por el privilegio de ser RESTful? Si no estuviera usando map.resources para agregar los objetos REST, las rutas estándar :controller/:action, :controller/:action/:id map.resources :controller/:action, :controller/:action/:id manejarían prácticamente todo automáticamente.

Answer 1

Consideraría la search como un caso especial de index . Ambas acciones devuelven una colección de recursos. Los parámetros de solicitud deben especificar cosas como página, límite, orden de clasificación y consulta de búsqueda.

Por ejemplo:

/resources/index # normal index
/resources/index?query=foo # search for ''foo''

Y en resources_controller:

before_filter :do_some_preprocessing_on_parameters
def index
@resources = Resource.find_by_param(@preprocessed_params)
end

En cuanto a index_full y search_by_name , puede considerar dividir su controlador actual en dos. Hay un olor a lo que has descrito.

Una vez dicho esto, tiene toda la razón en que no tiene sentido forzar a su aplicación a utilizar rutas de descanso del usuario cuando no entrega nada en /:controller/:action/:id . Para tomar una decisión, observe la frecuencia con la que está utilizando los ayudantes relajantes de la ruta de recursos en formularios y enlaces. Si no los estás usando, no me molestaría con eso.

Answer 2

En mi opinión, es posible que se hayan alejado un poco de la situación aquí. ¿Qué pasó con DRY?

Acabo de regresar a Rails sin haber hecho mucho desarrollo desde la versión beta y todavía estoy esperando que la bombilla aparezca aquí. Todavía estoy dando una oportunidad, pero si no me ha sucedido al final de mi proyecto actual, probablemente solo me regrese a las rutas estándar anteriores y defina los métodos, ya que realmente los necesito para el próximo. .

Answer 3

No voy a explicar más sobre REST ya que creo que ha sido respondido en esta pregunta, sin embargo, hablaré un poco sobre la ruta predeterminada.

Mi principal problema con la ruta predeterminada es que si tienes varios sitios usando la misma aplicación de Rails, puede parecer horrible.

Por ejemplo, puede haber controladores que no desea que las personas puedan ver en una aplicación:

http://example1.somesite.com/example_2/foo/bar/1

comparar esto con

/:controller/:action/:id

Esto iría al controlador example_2 / foo, barra de acción e id 1

Considero que este es el principal defecto de la ruta predeterminada de Rails y esto es algo que las rutas RESTful (con extensiones de subdominios) o solo las rutas con nombre ( map.connect ''foo'' ...) pueden arreglar.

Answer 4

Para permanecer RESTful en su diseño, debe reconsiderar lo que llama un recurso.

En su ejemplo, una acción de mostrar para un controlador de búsqueda, (recurso de búsqueda) es la dirección para permanecer tranquilo.

En el mío, tengo un controlador de tablero de instrumentos (show) y controladores para campos individuales de ecditors en el lugar (mostrar y actualizar)

Answer 5

REST no especifica que no puede tener vistas adicionales. Ninguna aplicación del mundo real podrá usar solo las acciones provistas; esta es la razón por la que puede agregar sus propias acciones.

REST consiste en poder hacer llamadas sin estado al servidor. Su acción de búsqueda no tiene estado cada vez que los datos hasta el momento se devuelven, ¿correcto? Su acción de visualización alternativa también es sin estado, solo una vista diferente.

En cuanto a si deberían ser rutas manuales o un nuevo controlador, eso depende de cuán distinta sea la actividad. Su vista alternativa, si proporciona un conjunto completo de operaciones CRUD (crear, leer, actualizar, eliminar) haría bien en estar en un nuevo controlador. Si solo tiene una vista alternativa de los datos, solo agregaría una acción de vista alternativa.

En otras palabras, no parece que su aplicación no sea RESTful, es más una cuestión de darse cuenta de que el conjunto de características generado automáticamente es un punto de partida, no una conclusión.

Answer 6

Si voy más allá de las acciones estándar de CRUD con mis modelos, normalmente solo agrego los métodos necesarios. La búsqueda es algo que agrego a muchos controladores, pero no a todos, así que lo agrego y mantengo las rutas normalmente:

map.resources :events, :collection => { :search => :get }

Mover estas acciones a un controlador completamente separado podría mantener algunos de sus controladores RESTful, pero creo que mantenerlos en contexto es mucho más útil.