Ruby on Rails - различение множественного числа от единственного ресурса в REST API

Question

Я работаю над созданием URL-адресов для моего REST API, прежде чем начну писать какой-либо код. Волшебство Rails REST - это фантастика, но меня немного беспокоит форматирование URL, например:

http://myproject/projects/5

, где Project - мой ресурс, а 5 - project_id. Я думаю, что если пользователь хочет получить все свои проекты, то соответствующий HTTP GET http://myproject/projects имеет смысл. Однако, если они хотят получить информацию о единственном ресурсе, таком как проект, то имеет смысл иметь http://myproject/project/5 против http://myproject/projects/5. Лучше ли избегать этой головной боли, или у некоторых из вас есть похожая проблема, а еще лучше - есть рабочее решение?

Answer 1

Rails (3) имеет много соглашений, когда речь идет о единственном и множественном числе. Например, классы моделей всегда единичны (Person), а соответствующие таблицы всегда во множественном числе (people). (Например, Person.all отображается на select * from people.)

Для маршрутов существует понятие единственного ресурса, а также множественного ресурса. Поэтому, если вы сделали resource :account, вы бы получили пути, такие как /account для пути по умолчанию или /account/edit для пути к форме для редактирования учетной записи. (Обратите внимание, что Rails использует /account с методом PUT для фактического обновления учетной записи. /account/edit - это форма для редактирования учетной записи, которая является отдельным ресурсом от самой учетной записи.) Однако, если вы сделали resources :people тогда вы получите пути типа /people, /people/1 и /people/1/edit. Сами пути указывают, может ли быть только один экземпляр данного типа ресурса, или может ли быть несколько экземпляров, различаемых по некоторому типу идентификатора.

Answer 2

Согласен, плывите по течению. Посмотрите, как URL формирует иерархию.

Корень вашего сайта - это то, где вы начинаете получать доступ ко всему.

/ projects / сужает его до одних проектов, а не чего-либо еще. Из проектов вы можете делать множество вещей, / list, / index /, / export и т. Д. / Id ограничивает вещи еще больше.

В каждом / сфера действия становится уже, и я думаю, что это имеет смысл.

Дальнейшее программирование - это произвольные правила. Индексы начинаются с 1 против 0 и т. Д. Любой, кто работает с вашими URL, будет разбираться в короткие сроки.

Answer 3

В некоторых случаях полезен отдельный путь к ресурсу. Если ваши идентификаторы ресурсов являются нечисловыми именами, определенными пользователем, возможны конфликты маршрутизации. Пример:

/ application / new -> создать новое приложение или показать приложение пользователя с именем new?

В этой ситуации вы можете ограничить пользовательский ввод, чтобы избежать конфликта, или это можно обойти, переписав поведение Rails 3 по умолчанию:

class ActionDispatch::Routing::Mapper
  module Resources
    RESOURCE_OPTIONS  << :singular_resource
    class Resource
      def member_scope
        @options[:singular_resource] ? "#{singular}/:id" : "#{path}/:id"
      end

      def nested_scope
        @options[:singular_resource] ? "#{singular}/:#{singular}_id" : "#{path}/:#{singular}_id"
      end
    end
  end
end

Тогда при указании нового ресурса маршрута:

resources :applications, :singular_resource => true

Который будет генерировать маршруты:

    GET     /applications
    GET     /applications/new
    POST    /applications
    GET     /application/:id
    GET     /application/:id/edit
    PUT     /application/:id
    DELETE  /application/:id