¿Por qué la convención dice que los nombres de tablas DB deben ser singulares pero los recursos RESTful en plural?

27

Es una convención bastante establecida que los nombres de tablas de bases de datos, al menos en SQL, deben ser singulares. SELECT * FROM user;Vea esta pregunta y discusión .

También es una convención bastante establecida que los nombres de recursos RESTful API deben ser plurales. GET /users/123yPOST /users mira este .

En la API respaldada por base de datos más simple, el nombre del recurso en la URL sería la tabla, y los elementos de datos en la URL y los cuerpos de solicitud / respuesta se asignarían directamente a las columnas en la base de datos. Conceptualmente, no veo una diferencia entre operar en los datos a través de esta API teórica versus operar en ella directamente a través de SQL. Y debido a eso, la diferencia en las convenciones de nombres entre usery usersno tiene sentido para mí.

¿Cómo puede justificarse la diferencia en la pluralización cuando, conceptualmente, la API REST y el SQL están haciendo lo mismo?

smitelli
fuente
3
No existe una convención única en el nombre de la tabla DB ni el nombre de recursos RESTful que todos siguen. Por el contrario, puede haber muchas convenciones. No es sorprendente que algunos puedan chocar.
Eric King
13
No existe tal convención establecida. Siempre he usado nombres de tablas en plural. usuarios , cuentas , etc., ya que tienen más de una de esas cosas.
GrandmasterB
2
@GrandmasterB La convención existe y tiene su origen en el modelo relacional de Codd donde las "relaciones" (que se convierten en tablas, que no deben confundirse con las relaciones) tienen nombres singulares porque una relación es una lista de cosas, no varias listas de cosas. Cada relación es una lista. Relaciones modelo de entidades de dominio. Los nombres de las entidades son singulares en el modelo relacional de Codd. Hay abundante literatura al respecto que dice que no existe. Pero está perfectamente bien que use nombres plurales si lo desea.
Tulains Córdova
44
@ user61852 Hay personas que pueden usarlo por convención. Pero de ninguna manera es una convención de la industria ampliamente seguida como se presenta en esta pregunta en la forma, digamos, que es camelCase o MarkDown.
GrandmasterB
44
También tenga en cuenta que REST no es un protocolo de acceso a la base de datos. No hay razón para que las convenciones de nomenclatura de bases de datos (cualquiera con la que vaya) y las convenciones de nomenclatura de URL (con la que vaya) sean similares, no tienen nada que ver entre sí. Dos dominios muy diferentes. Ya no tiene sentido reflexionar sobre por qué las bases de datos usan singular y las URL usan plural que reflexionar sobre por qué las bases de datos usan single, pero mi administrador del sistema nombra en plural sus directorios del sistema de archivos. Los marcos web mal diseñados hacen que la gente piense que REST es algo que tiene que ver con el acceso a la base de datos, pero no lo es.
Cormac Mulhall

Respuestas:

12

La especificación REST (cualquier nivel con el que desee ir) no se diseñó como acceso a la base de datos. Está tratando de llevar la estandarización al acceso a la API. Las convenciones de SQL mencionadas (si desea usarlas o no) no se diseñaron teniendo en cuenta el acceso a la API. Son para escribir consultas SQL.

Entonces, el problema para desempaquetar aquí es la comprensión conceptual de que una API se asigna directamente a la base de datos. Podemos encontrar esto descrito como un antipatrón al menos desde 2009 .

¿La razón principal por la que esto es malo? El código que describe "¿cómo afecta esta operación a mis datos?" se convierte en código de cliente .

Esto tiene algunos efectos terribles en la API. (no es una lista exhaustiva)

Hace que la integración con la API sea difícil

Me imagino los pasos para crear un nuevo usuario documentado como algo así:

  1. POST /users { .. }
  2. POST /usersettings { .. } con algunos valores predeterminados
  3. POST /confirmemails { .. }

Pero, ¿cómo manejas una falla del paso 2? ¿Cuántas veces es esta misma lógica de manejo copiada a otros clientes de su API?

Estas operaciones de datos son a menudo más fáciles de secuenciar en el lado del servidor, mientras se inician desde el cliente como una sola operación. Por ej POST /newusersetup. Los DBA pueden reconocer esto como un procedimiento almacenado, pero la operación de la API puede tener efectos más allá de la base de datos.

Asegurar la API se convierte en un agujero negro de desesperación

Digamos que necesita fusionar dos cuentas de usuario.

  1. GET /users/1
  2. PUT /users/2 { .. }
  3. DELETE /users/1

¿Cómo va a configurar un permiso de usuario para permitir la función de combinación sin permitir la eliminación del usuario? ¿La eliminación de un usuario está incluso representada de manera justa DELETE /users/1cuando /usersettingstambién existe?

Las operaciones de API deben considerarse operaciones de nivel superior (que la base de datos) que pueden causar múltiples cambios en el sistema.

El mantenimiento se vuelve más difícil

... porque sus clientes dependen de la estructura de su base de datos.

Según mi experiencia con este escenario:

  • No puede renombrar o eliminar tablas / columnas existentes. Incluso cuando se nombran incorrectamente para su función o ya no se usan. Los clientes se romperán.
  • Las nuevas características no pueden cambiar las estructuras de datos existentes, por lo que sus datos y funcionalidad a menudo se separan artificialmente, incluso cuando pertenecen de manera integral a una característica existente.
  • La base del código gradualmente se vuelve más difícil de entender debido a la fragmentación, los nombres confusos y el equipaje sobrante que no se puede quitar de manera segura.
  • Todos los cambios, menos triviales, se vuelven cada vez más riesgosos y requieren mucho tiempo.
  • El sistema se estanca y finalmente se reemplaza.

No exponga la estructura de su base de datos directamente a los clientes ... especialmente a los clientes sobre los que no tiene control de desarrollo. Use una API para limitar el cliente a solo operaciones válidas.

Entonces, si está utilizando una API como solo una interfaz directamente en una base de datos, la pluralización es la menor de sus preocupaciones. Para otro experimento que no sea tirar, sugeriría pasar un tiempo determinando las operaciones de nivel superior que la API debería representar. Y cuando lo miras de esa manera, no hay conflicto entre los nombres de entidades API pluralizadas y los nombres de entidades SQL singulares. Están allí por diferentes razones.

Kasey Speakman
fuente
1
Responde una pregunta diferente. OP no implica asociación directa de entidades API y DB, solo presencia de algunas entidades en ambos contextos.
Basilevs
2
Siéntase libre de publicar una respuesta a la pregunta que cree que se le está haciendo.
Kasey Speakman
44
@Basilevs En realidad, creo que esto responde la pregunta. A veces las respuestas pueden parecer indirectas cuando una pregunta se enmarca en suposiciones incorrectas. La "presencia de algunas entidades en ambos contextos" implica que son las mismas entidades, lo que implica una correspondencia 1 a 1 entre algunas y no otras. Tal correspondencia de una API sobre un modelo de datos complejo implica un diseño defectuoso.
Aluan Haddad
Entre estas hay muchas razones por las que dejé de usar Spring Data Rest.
Sebastiaan van den Broek
4

REST API y SQL NO están "haciendo lo mismo"

El OP pregunta:

¿Cómo puede justificarse la diferencia en la pluralización cuando, conceptualmente, la API REST y el SQL están haciendo lo mismo?

Ah, pero saltamontes, puede parecer que la interfaz RESTful y las tablas SQL "están haciendo lo mismo", pero una buena higiene de la programación nos dice que siempre hay una capa intermedia que media entre la API REST y la base de datos. ¡Ignorar este punto es desviarse del camino hacia la iluminación del software! :)

Por lo tanto, las API RESTful y las tablas SQL pueden seguir felizmente sus propias convenciones de nomenclatura idiomáticas, que están bien documentadas y discutidas a fondo en otros lugares.

temerario
fuente