Quando si dovrebbero utilizzare i controller RESTful in un'applicazione Rails e quando non si dovrebbe?

Question

Sto cercando delle linee guida su quando sapere quando un approccio RESTful a un modello e alle sue associazioni è corretto, e quando non lo è. Forse è la natura della mia attuale applicazione, ma sto scoprendo che i modelli semplici senza associazioni funzionano bene con REST, ma i modelli complessi con molte has_many associates sembrano davvero complicare la vista e l'impostazione richiesta nel controller. form_for le chiamate iniziano a diventare particolarmente complicate.

O forse è la mia comprensione neofita. Ho lavorato su Rails per oltre tre anni, ma REST e formatori insieme mi sembrano mistificarmi.

Answer 1

Crea una risorsa per ogni modello di livello superiore nel tuo sistema. Per alto livello, intendo i modelli che sono indipendenti e hanno un significato al di fuori del modello associato. Generalmente, questa è la maggior parte dei modelli. Nel seguente esempio Position and Candidate sono di primo livello. Potresti considerare Candidato composto da PastEmployment e posizioni a cui ha applicato. È possibile accedere alle applicazioni alle posizioni e alla cronologia di lavoro precedente tramite la risorsa Candidato, poiché non esistono per conto proprio.

modelle

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 

Itinerari

map.resources :positions 
map.resources :candidates 

Utilizzare un controller non di risorse per le interazioni con l'utente che si estendono modelli. Ad esempio, se si desidera avere uno HomeController che mostra le posizioni disponibili e i candidati recenti, si tratterebbe di un nuovo controller semplice. Se vuoi modificare qualsiasi informazione su questo controller, cool! Hai già a disposizione i controller per gestire i post dei moduli, che verranno automaticamente cablati con <% form_for @candidate %>. Puoi rendere la tua collezione di posizioni con <%= render @positions %>, e dato che le hai rese una risorsa, Rails saprà di cercare in views/positions/_position.html.erb per il parziale appropriato.

Il risultato finale dovrebbe essere che non si scrive mai la logica per gestire la persistenza di un oggetto in più di una posizione. Ecco quando i controller diventano complessi e le forme sfuggono di mano. Significa anche che Rails e sistemi esterni sanno dove recuperare e memorizzare gli oggetti. Stesso URL, stesso controller, solo un formato diverso.

Answer 2

Non conosco RoR, quindi farò generare dichiarazioni su REST.

REST e ROI considerano gli URL come serie di nomi e utilizza come metodi i metodi HTTP come GET, POST, PUT e DELETE. Questo modello funziona per CRUD e anche per i modelli con più associazioni. Poiché gli URL rappresentano risorse, gli oggetti associati possono essere espressi come elenco di URL.

Tuttavia, se il sistema richiede più verbi a grana fine come convalida, spostamento, copia, suoneria, lettura, scrittura ecc., Potrebbe non essere adatto a REST.

Answer 3

disclaimer: conosco i binari, ma sono ancora un principiante. Risposta breve: REST e gli helper dei moduli sono aree completamente diverse.

Risposta lunga: A quanto ho capito, il trasferimento dello stato di rappresentanza è solo approssimativamente collegato al rendering effettivo di forme e viste.

REST ha davvero a che fare con i controller e con alcuni modelli di estensione. L'idea è che invece di provare a pensare a un'intera conversazione con un cliente, si scrive una webapp per rispondere in modo specifico e prevedibile ai singoli messaggi del client.

Ad esempio, se un client ottiene un modello, lo si recupera, lo formatta per loro, lo invia a loro e si dimentica di esso. se un client esegue un aggiornamento di qualche tipo, si modifica lo stato di webapps per rispecchiarlo, inviare qualsiasi risposta e poi dimenticarsene. Qualsiasi futuro GET o POST guarderà al nuovo stato, ma non al messaggio che lo ha creato.

Quindi, davvero, indipendentemente dal fatto che un'applicazione sia o meno RESTful dipende non tanto da quanto è complicato il modello, ma da come gli utenti interagiscono con esso. Un'app pensata per essere almeno un po 'client-agnostica, cioè incentrata sui dati, è un buon candidato per REST. Qualcosa che fa molto affidamento sulle sessioni e che interagisce con un utente specifico, ed è incentrato sui processi, potrebbe non essere un buon candidato.

D'altra parte, si dispone di guide in formato Rails. Questi sono ottimi per l'impalcatura, ma a volte possono essere frustranti quando si tenta di usarli in modi più complicati.

Quindi, qual è la tua domanda principale? Hai una domanda specifica sulle guide di forma dei binari? sui controller di rotaie? o qualcosa di specifico per REST?

Answer 4

Si potrebbe verificare questa serie di Railscasts, che parla dispone di-molti sulle relazioni e le forme nel contesto di REST:

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