Diseño RESTful, cómo nombrar páginas fuera de CRUD et al?

Question

Estoy trabajando en un sitio que tiene un buen número de páginas que quedan fuera de mi limitada comprensión del diseño de REST, que es esencialmente:

Create, Read, Update, Delete, Show, List 

aquí está la pregunta: ¿qué es un buen sistema de etiquetado acciones/rutas cuando una página no cae claramente en CRUD/show/list? Algunas de mis páginas tienen información sobre múltiples tablas a la vez. Estoy construyendo un sitio que da a algunos clientes una 'base de operaciones' después de iniciar sesión. NO les proporciona ninguna información sobre sí mismos, por lo que no debería ser, por ejemplo,/customers/show/1. Tiene información sobre compañías, pero hay otras páginas en el sitio que lo hacen de manera diferente. ¿Qué haces cuando tienes estas situaciones? Esta 'base de operaciones' se muestra a los clientes y principalmente tiene información sobre las empresas (pero no de forma exclusiva).

Segundo caso: Tengo una tabla llamada 'Emparejamientos' entre clientes y empresas. Estas coincidencias se acceden de maneras completamente diferentes en diferentes partes del sitio (diferentes diseños, diferentes hojas de CSS, diferentes tipos de usuarios que acceden a ellas, etc.). No pueden TODOS ser emparejamientos/show. ¿Cuál es la mejor manera de etiquetar a los demás?

muchas gracias. =)

Answer 1

ciertamente no soy experto, pero si replantearse sus recursos y pensar en ellos más estrictamente como sustantivos '' o por lo menos listas de datos, que podrían ser más fáciles de encajar cualquier acción deseada en GET, POST, PUT y DELETE. Por ejemplo, tiene un recurso /customers/ que podría presumiblemente tener un recurso /customers/{username}/ para cada cliente. Tal vez eso les da información sobre ellos mismos. Puede tener /homebases/{username}/ o /customers/{username}/homebase/ como recursos de su homebase. Presumiblemente, accedería a ese recurso homebase principalmente a través de GET, y POST si hay algo allí para actualizar (que no esperaría en una base de operaciones doméstica o tablero de instrumentos, ya que es un recurso agregado).

Para 'emparejamientos' puede usar algo como /matchings/{customer},{company}/ (sí, se permiten comas y puntos y comas. Comas generalmente significa que las dos partes dependen del orden y punto y coma significa independiente del orden, aunque no hay reglas al respecto). A partir de ese recurso, puede hacer que GET lea, muestre y liste los datos que necesita (incluidos los parámetros de consulta opcionales pasados ​​como cuerpo de la solicitud GET), POST para actualizar, PONER para crear y ELIMINAR para eliminar. Usando los parámetros pasados ​​en GET, también podría solicitar diferentes vistas de los mismos datos. Por supuesto, puede tener sub-recursos de esa coincidencia como /matchings/{customer},{company}/invoices/{invoice#}/.

Me gustó el libro "RESTful Web Services" (2007 O'Reilly), por cierto.

Espero que tenga sentido y sea útil. =)

Answer 2

Las vistas agregadas y compuestas son un problema serio, creo. Tuve que lidiar con el problema homepage que iba en contra de todo lo RESTful que sabía.

Mi solución fue considerar la página de inicio o el tablero como un recurso en sí mismo, pero un recurso donde solo las operaciones GET tenían sentido. POST/PUT/DELETE desde la página de inicio fueron dirigidos a los recursos específicos como de costumbre.

Coincidencias, en cambio, parece un problema más fácil de domar. Parece una simple asignación entre Clientes y Empresas a partir de su descripción, y podría parametrizarla en función de los parámetros de la cadena de consulta.

/matchings?companies=X,Y,Z&locations=NY,CA,TX 

Answer 3

Por diseño REST, supongo que te refieres servicios web RESTful, desde una arquitectura basada en REST tiene un sentido mucho más amplio que eso.

Lo principal a tener en cuenta es que las arquitecturas basadas en REST se basan en el protocolo HTTP, en prácticamente todos los casos. Como HTTP especifica un conjunto de métodos, a veces estos métodos se usan para crear los llamados servicios web RESTful.

Pero los servicios web RESTful no siguen ningún estándar concreto (a diferencia de SOAP). Es común el uso de:

• GET - para traer los artículos existentes
• POSTAL - para la creación de nuevos artículos
• PUT - para la actualización de los elementos existentes
• DELETE - para eliminando elementos existentes

Crear, leer, actualizar y eliminar (CRUD) son las funciones básicas de cualquier almacenamiento persistente.

Es fácil ver que en los servicios web RESTful comunes, cada método HTTP está siendo utilizado para que coincida con una de las funciones básicas, pero el punto es: no tiene por qué ser así.

Hay otras cosas a considerar, asignación de dirección URL es uno de ellos (ya que es la preocupación de su pregunta), la seguridad es otro. Las solicitudes POST envían el contenido de la solicitud en el cuerpo HTTP (que se puede encriptar), pero las solicitudes GET lo envían en la URL, visible para que todos puedan ver.

Si se desea desarrollar un servicio web RESTful seguro (encriptado), se pueden realizar todas las solicitudes HTTPS POST, y luego especificar dentro de la solicitud, cuál de las operaciones CRUD se desea realizar y con qué recursos.

También se podría ampliar el concepto CRUD a una gama más amplia, de hecho, en casi todas las aplicaciones, uno tiene que.

Recuerde CRUD son sólo las cuatro operaciones básicas en las que todas las demás acciones puedan construir. No hay un estándar que tenga que seguir, puede especificar su propio protocolo, según lo que tenga sentido en su contexto y tenga en cuenta todas las consideraciones relevantes (seguridad, URL, etc.)

Específicamente con respecto a su pregunta, usted puede tener sus propias acciones, como show_by_x, show_by_y, etc. La policía de REST no viene para arrestarte :-)

Answer 4

REST y ORM son 2 cosas diferentes, debido a eso a pesar de que tienes un modelo llamado Usuario, hecho necesario para tener un recurso de usuario.Los recursos deben ser gestionados en el nivel del controlador rieles

recursos que como módulos/secciones

Ex: es posible que desee a los usuarios a la tierra en una página de panel después de iniciar sesión en (y que tiene dos categorías de Administradores de usuarios y los usuarios normales), lo que puede tener dos recursos namly

admin_dashboard uer_dashboard

y ambos sólo se podría haber leído la acción

Segunda ca SE:

considerar la posibilidad de algo así como el ejemplo anterior (diferentes recursos de acuerdo con diferentes niveles de usuario) si es posible

No soy un gurú de descanso, pero espero que esto ayude: D

aplausos, sameera