Когда следует использовать контроллеры RESTful в приложении Rails, а когда нет?

Question

Я ищу рекомендации о том, когда знать, когда подход RESTful к модели и ее ассоциациям является правильным, а когда - нет. Возможно, это характер моего текущего приложения, но я обнаружил, что простые модели без ассоциаций хорошо работают с REST, но сложные модели со многими ассоциациями has_many действительно усложняют представление и настройку, требуемую в контроллере. вызовы form_for начинают становиться особенно сложными.

Или, может быть, это мое понимание неофита. Я занимаюсь Rails уже более трех лет, но REST и помощники по формам вместе, кажется, озадачивают меня.

Answer 1

Создайте ресурс для каждой модели верхнего уровня в вашей системе. Под верхним уровнем я подразумеваю модели, которые являются независимыми и имеют значение вне соответствующей модели. Как правило, это большинство моделей. В следующем примере Position и Candidate являются верхними уровнями. Вы можете считать, что Кандидат состоит из PastEmployment и должностей, на которые она претендовала. Приложения к должностям и предыдущей истории работы могут быть доступны через ресурс кандидата, так как они не существуют самостоятельно.

Модель

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

Маршруты

map.resources :positions
map.resources :candidates

Используйте нересурсный контроллер для взаимодействия с пользователем, который охватывает модели. Например, если вы хотите иметь HomeController, который показывает доступные позиции, а также недавних кандидатов, это будет новый, простой контроллер. Если вы хотите редактировать любую информацию на этом контроллере, круто! У вас уже есть контроллеры для обработки сообщений формы, которые будут автоматически соединены с <% form_for @candidate %>. Вы можете визуализировать свою коллекцию позиций с помощью <%= render @positions %>, и, поскольку вы сделали их ресурсом, Rails узнает, что нужно искать в views/positions/_position.html.erb соответствующий партиал.

Конечным результатом должно быть то, что вы никогда не пишете логику для обработки постоянства объекта в более чем одном месте. Именно тогда контроллеры становятся сложными, а формы выходят из-под контроля. Это также означает, что Rails и внешние системы знают, где искать и хранить объекты. Тот же URL, тот же контроллер, просто другой формат.

Answer 2

Вы можете проверить эту серию Railscasts, в которой говорится о связях has-many и формах в контексте REST:

• Сложные формы, часть 1
• Сложные формы Часть 2
• Сложные формы, часть 3

Answer 3

отказ от ответственности: я знаю рельсы, но я все еще новичок. Краткий ответ: помощники REST и формы - это совершенно разные области.

Длинный ответ: Насколько я понимаю, передача состояния представительства слабо связана с фактическим отображением форм и представлений.

REST действительно имеет отношение к контроллерам и в определенной степени к моделям. Идея состоит в том, что вместо того, чтобы пытаться думать о целой беседе с клиентом, вы пишете веб-приложение, которое отвечает определенным, предсказуемым образом на отдельные сообщения клиента.

Т.е., если клиент ПОЛУЧАЕТ модель, вы просто извлекаете ее, форматируете для них, отправляете им и забываете об этом. если клиент помещает какое-либо обновление, вы изменяете состояние веб-приложений, чтобы отразить это, отправляете обратно любой ответ, а затем забываете об этом. Любое будущее GET или POST будет смотреть на новое состояние, но не на сообщение, которое его создало.

Таким образом, действительно, является ли приложение RESTful или нет, зависит не только от того, насколько сложна модель, но и от того, как пользователи взаимодействуют с ней. Приложение, которое должно быть, по крайней мере, несколько клиент-независимым, то есть ориентированным на данные, является хорошим кандидатом на REST. То, что в значительной степени зависит от сеансов и взаимодействует с конкретным пользователем и ориентировано на процессы, может оказаться не таким хорошим кандидатом.

С другой стороны, у вас есть помощники по Rails. Они отлично подходят для строительных лесов, но иногда могут разочаровывать, когда вы пытаетесь использовать их более сложными способами.

Итак, каков ваш главный вопрос? У вас есть конкретный вопрос о помощниках по рельсам? про рельсы контроллеров? или что-то конкретное для ОТДЫХА?

Answer 4

Я не знаю RoR, поэтому я буду генерировать операторы для REST.

REST и ROI обрабатывают URL-адреса как серии существительных и используют методы HTTP, такие как GET, POST, PUT и DELETE, в качестве глаголов. Эта модель работает для CRUD и даже для моделей с несколькими ассоциациями. Поскольку URL-адреса представляют ресурсы, связанные объекты можно выразить в виде списка URL-адресов.

Однако если вашей системе требуются более мелкие глаголы, такие как проверка, перемещение, копирование, сигнализация, чтение, запись и т. Д., Это может не подходить для REST.