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

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?

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.

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.