Ruby on Rails: diferencia entre el recurso plural y el singular en una API REST

Question

Estoy trabajando en la construcción de las URL para mi API REST antes de comenzar a escribir cualquier código. Raíles RESTO magia es fantástica, pero me molesta un poco el formato de un enlace como:

http://myproject/projects/5

donde es mi proyecto de recursos y 5 es la project_id. Creo que si un usuario está buscando recuperar todos sus proyectos, entonces un HTTP GET http://myproject/projects tiene sentido. Sin embargo, si buscan recuperar información sobre un recurso singular, como un proyecto, entonces tiene sentido tener http://myproject/project/5 frente a http://myproject/projects/5. ¿Es mejor evitar este dolor de cabeza, o algunos de ustedes comparten una preocupación similar y aún mejor, tienen una solución de trabajo?

Answer 1

Rails (3) tiene muchas convenciones cuando se trata de singular vs plural. Por ejemplo, las clases de modelo son siempre singulares (Person), mientras que las tablas correspondientes siempre son plurales (people). (Por ejemplo, Person.all mapas a select * from people.)

Para las rutas, hay un concepto de recurso singular así como un recurso plural. Entonces, si hiciera resource :account, obtendría rutas como /account para la ruta predeterminada o /account/edit para una ruta a un formulario para editar la cuenta. (Tenga en cuenta que Rails usa /account con un método PUT para actualizar realmente la cuenta. /account/edit es un formulario para editar la cuenta, que es un recurso separado de la cuenta misma). Si lo hizo resources :people, entonces obtendría rutas como /people , /people/1 y /people/1/edit. Las rutas en sí mismas indican si solo puede haber una instancia de un tipo determinado de recurso, o si puede haber varias instancias distinguidas por algún tipo de identificador.

Answer 2

Estoy de acuerdo, vaya con la corriente. Considere cómo la URL forma una jerarquía.

La raíz de su sitio web es donde comienza a acceder a cualquier cosa.

/projects/lo reduce a solo proyectos, nada más. Desde proyectos, puede hacer muchas cosas,/list,/index /,/export, etc ... el/id limita aún más las cosas.

En cada uno/el alcance de lo que se vuelve más estrecho, y creo que tiene sentido.

La programación adicional se trata de reglas arbitrarias. Los índices comienzan en 1 vs 0, y así sucesivamente. Cualquiera que trabaje con tus URL resolverá las cosas en poco tiempo.

Answer 3

Hay casos en que una ruta de acceso singular a un recurso es útil. Si los identificadores de recursos son nombres no numéricos definidos por el usuario, entonces los conflictos de enrutamiento son posibles. Ejemplo:

/applications/new -> crear una nueva aplicación o mostrar la aplicación del usuario llamada nueva?

En este caso se puede optar por limitar la entrada del usuario para evitar el choque, o, esto se puede evitar mediante la sobreescritura de los rieles por defecto 3 comportamiento:

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 

A continuación, cuando se especifica una nueva ruta de recursos:

resources :applications, :singular_resource => true 

que generará las rutas:

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