¿Cuándo debería usar los controladores RESTful en una aplicación de Rails, y cuándo no?

Question

Estoy buscando pautas sobre cuándo saber cuándo es correcto un enfoque RESTful para un modelo y sus asociaciones, y cuándo no. Tal vez sea la naturaleza de mi aplicación actual, pero estoy descubriendo que los modelos simples sin asociaciones funcionan bien con REST, pero los modelos complejos con muchas asociaciones has_many realmente parecen complicar la vista y la configuración requerida en el controlador. form_for llamadas comienzan a ser especialmente complicado.

O tal vez es mi comprensión neófita. He estado haciendo Rails durante más de tres años, pero REST y formadores juntos parecen desconcertarme.

Answer 1

Haga un recurso de cada modelo de nivel superior en su sistema. Por nivel superior, me refiero a modelos que son independientes y tienen significado fuera del modelo asociado. En general, esa es la mayoría de los modelos. En el siguiente ejemplo, Position y Candidate son de nivel superior. Podría considerar Candidate para estar compuesto de PasadoEmpleo y puestos a los que ha aplicado. Se puede acceder a las solicitudes a los puestos y al historial de trabajo anterior a través del recurso Candidato, ya que no existen por sí solos.

Modelos

class Position 
    has_many :candidate_positions 
    has_many :candidates, :through => :candidate_positions 
end 

class Candidate 
    has_many :candidate_positions 
    has_many :positions, :through => :candidate_positions 
    has_many :past_employments 
    accepts_nested_attributes_for :past_employments 
    accepts_nested_attributes_for :candidate_positions 
end 

class PastEmployment 
    belongs_to :candidate 
end 

class CandidatePosition 
    belongs_to :candidate 
    belongs_to :position 
end 

Rutas

map.resources :positions 
map.resources :candidates 

Utilice un controlador que no inventivo para la interacción con el usuario que abarcan modelos. Por ejemplo, si desea tener un HomeController que muestre las posiciones disponibles, así como los candidatos recientes, ese sería un controlador nuevo y sencillo. Si desea editar cualquiera de la información en este controlador, ¡genial! Ya tiene controladores disponibles para manejar las publicaciones del formulario, que se conectarán automáticamente con <% form_for @candidate %>. Puede representar su colección de posiciones con <%= render @positions %>, y como las ha convertido en un recurso, Rails sabrá buscar en el views/positions/_position.html.erb el parcial correspondiente.

El resultado final debe ser que nunca se escribe lógica para manejar la persistencia de un objeto en más de un lugar. Es entonces cuando los controladores se vuelven complejos y las formas se salen de control. También significa que Rails y sistemas externos saben dónde recuperar y almacenar objetos. Misma URL, mismo controlador, solo un formato diferente.

Answer 2

No sé RoR, entonces haré generar declaraciones en REST.

REST y ROI trata las URL como series de sustantivos, y utiliza métodos HTTP como GET, POST, PUT y DELETE como verbos. Este modelo funciona para CRUD e incluso para modelos con asociaciones múltiples. Dado que las URL representan recursos, los objetos asociados se pueden expresar como una lista de URL.

Sin embargo, si su sistema requiere más verbos de grano fino como validar, mover, copiar, tocar la bocina, leer, escribir, etc., puede no ser adecuado para REST.

Answer 3

descargo de responsabilidad: Conozco los rieles, pero todavía soy bastante novato. Respuesta corta: REST y ayudantes de formulario son áreas completamente diferentes.

Respuesta larga: Según tengo entendido, la Transferencia de estado representacional solo está vagamente relacionada con la representación real de formularios y vistas.

REST realmente tiene que ver con los controladores, y hasta cierto punto con los modelos. La idea es que, en lugar de tratar de pensar en una conversación completa con un cliente, usted escriba una aplicación web para responder de manera específica y predecible a los mensajes individuales de los clientes.

es decir, si un cliente OBTIENE un modelo, simplemente lo recupera, lo formatea, se lo envía y se olvida de él. si un cliente REALIZA una actualización de algún tipo, usted cambia el estado de las aplicaciones web para reflejar eso, envía de vuelta cualquier respuesta, y luego se olvida de eso. Cualquier futuro GET o POST mirará el nuevo estado, pero no el mensaje que lo creó.

Por lo tanto, realmente, el hecho de que una aplicación sea RESTful no depende realmente de cuán complicado sea el modelo, sino de cómo los usuarios interactúan con él. Una aplicación destinada a ser al menos un tanto agnóstica del cliente, que se centra en datos, es un buen candidato para REST. Algo que depende en gran medida de las sesiones e interactúa con un usuario específico, y se centra en el proceso, podría no ser un buen candidato.

Por otro lado, tiene Rails form helpers. Estos son excelentes para andamios, pero a veces pueden ser frustrantes cuando intenta usarlos de formas más complicadas.

Entonces, ¿cuál es su pregunta principal? ¿Tiene alguna pregunta específica sobre los rieles de los ayudantes? sobre los controladores de rieles? o algo específico para REST?

Answer 4

Es posible que echa un vistazo a esta serie de Railscasts, que habla de HAS-muchas relaciones y formas en el contexto de REST:

• Complex Forms Part 1
• Complex Forms Part 2
• Complex Forms Part 3