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í:
POST /users { .. }POST /usersettings { .. } con algunos valores predeterminadosPOST /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.
GET /users/1PUT /users/2 { .. }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.