2011-04-23 7 views
0

Je suis assez nouveau sur Rails 3 et j'essaie de comprendre l'avantage de concevoir une application de manière RESTful. Je n'ai pas besoin d'un service API/Web. Vous n'avez pas besoin de XML ou de JSON.Rails 3 Design RESTful préféré?

L'application que je construis n'utilise aucun CRUD du tout. C'est une application qui rassemble des données commerciales via une connexion socket et l'affiche de différentes façons pour un utilisateur.

Je voudrais visualiser les métiers de différentes façons telles que:

  • les plus récents
  • plus haut rendement
  • des métiers par l'Etat
  • métiers les plus actifs
  • millions de transactions en dollars
  • Opérations qui sont des obligations d'obligation générale
  • etc ...

Dans la "Rails Way", il semble que j'aurais une action d'index très surchargée. Ou je pourrais aller contre convention et juste créer des méthodes dans le contrôleur des métiers comme most_recent, Highest_yielding, most_active, etc. Mais cela semble aller à l'encontre de la philosophie de concevoir une application dans Rails 3.

Il semble juste que l'idée derrière une approche RESTful dans Rails est basé autour de CRUD et tombe court quand CRUD n'est pas impliqué. Y at-il vraiment un avantage à concevoir votre application pour qu'elle soit "RESTful" en plus de suivre une convention? Je ne vois pas vraiment l'avantage ici.

De plus, si je ne jamais besoin d'une API, j'imagine qu'il serait préférable de concevoir une API avec une API à l'esprit. Mon API ne serait pas un match direct de 1 à 1 de mon site construit pour la consommation humaine par rapport à une machine.

J'aimerais avoir un aperçu à ce sujet. Peut-être qu'il me manque quelque chose ici?

+0

CRUD est impliqué - toutes ces façons que vous avez listées pour "visualiser" des trades sont incluses dans la partie "R" de CRUD, qui signifie "read". –

+0

Je suppose que la meilleure façon de poser la question aurait été: Quelle est la meilleure façon de gérer les ressources qui sont «lues» lourdement. Est-ce qu'ils pointent tous vers une seule action d'index avec beaucoup d'instructions IF? Cela semble juste désordonné. C'est plus ce que je veux dire. – Dan

Répondre

1

CRUD est réellement impliqué lorsque des ressources sont impliquées. Et puisque pratiquement chaque application a des ressources, CRUD peut être impliqué et est habituellement (si vous me demandez), la meilleure façon de le faire.

L'idée est qu'une ressource a certaines actions. Vous visualisez une ressource, vous la modifiez, vous la supprimez et d'autres encore. Les méthodes comme most_recent (ou portée pour celui-ci) devraient être utilisées dans les modèles et non dans les contrôleurs. Ensuite, si vous avez besoin d'utiliser cette collection, vous devez simplement appeler quelque chose comme:

@recent_posts = Post.most_recent 

dans votre contrôleur. Vos contrôleurs ne devraient pas avoir beaucoup de code, en fait aucune logique métier du tout.

RESTful est très agréable car il gère les ressources naturellement. Un contrôleur devrait effectivement gérer une ressource. Si vous pensez que quelque chose peut être modifié ou créé, il doit être géré par un contrôleur.

En général, je suggère fortement que vous prenez un regard plus profond et vous allez certainement voir les avantages sur votre propre.

1

J'ai une idée de comment le faire. Le code n'est pas testé, je l'ai juste écrit sans courir.

Controller:

# trades_controller.rb 
def index 
    # all scopes defined in model will be allowed here 
    # not good idea if you don't want it 
    if Trade.scopes.has_key?(params[:scope].to_sym) 
    @trades = Trade.send(:params[:scope]) 
    else 
    # render error or what you want 
    end 
end 

Modèle

# trade.rb 
    scope :most_recent, order(:created_at) 
    # more scopes 

Voir

# index.html.erb 
link_to 'Most recent', trades_path(:scope => 'most_recent') 
+0

Cela a du sens. Je suppose que je pourrais décider de la vue à afficher en fonction de la portée. – Dan

0

Votre conception doit toujours prendre en compte les exigences de votre première application et la philosophie du deuxième cadre. Si la philosophie ne correspond pas à vos exigences ou à ce que vous croyez être la meilleure façon de développer votre application, alors ignorez-la, ou, si le cadre rend trop difficile pour vous de construire comme vous le pensez (ce qui est le cas). n'est pas le cas dans Rails imho), passez à un autre cadre.

Tout cela n'a pas grand chose à voir avec REST. Pour plus d'informations sur pourquoi REST est considéré comme une bonne idée (pour certains, pas tous, les choses), voir le SO suivant & A: Why would one use REST instead of Web services et What exactly is RESTful programming.