La specifica REST (qualsiasi livello tu voglia andare) non è stata progettata come accesso al database. Sta cercando di portare la standardizzazione all'accesso API. Le convenzioni SQL menzionate (se si desidera utilizzarle o meno) non sono state progettate pensando all'API. Sono per la scrittura di query SQL.
Quindi il problema di decomprimere qui è la comprensione concettuale che un'API mappa direttamente nel database. Possiamo trovare questo descritto come un anti-modello almeno fino al 2009 .
La ragione principale è cattiva? Il codice che descrive "in che modo questa operazione influisce sui miei dati?" diventa codice cliente .
Questo ha degli effetti piuttosto terribili sull'API. (non un elenco completo)
Rende difficile l'integrazione con l'API
Immagino i passi per creare un nuovo utente documentato come qualcosa del tipo:
-
POST /users { .. }
-
POST /usersettings { .. } con alcuni valori predefiniti
-
POST /confirmemails { .. }
Ma come gestisci un fallimento del passaggio n. 2? Quante volte la stessa logica di gestione copia-pasta su altri client della tua API?
These data operations are often easier to sequence on the server side, while being initiated from the client as a single operation. E.g. POST /newusersetup. DBAs may recognize this as a stored procedure, but the API operation may have effects beyond just the database.
La protezione dell'API diventa un buco nero di disperazione
Supponiamo di dover unire due account utente.
-
GET /users/1
-
PUT /users/2 { .. }
-
DELETE /users/1
Come hai intenzione di impostare un'autorizzazione utente per consentire la funzione di unione pur non consentendo l'eliminazione dell'utente? Eliminare un utente rappresentato in modo equo anche da DELETE /users/1 quando esiste anche /usersettings ?
API operations should be looked at as higher-(than-database)-level operations which may cause multiple changes in the system.
La manutenzione diventa più difficile
... perché i tuoi client dipendono dalla struttura del tuo database.
In base alla mia esperienza con questo scenario:
- Non è possibile rinominare o rimuovere tabelle / colonne esistenti. Anche quando vengono denominati in modo errato per la loro funzione o non vengono più utilizzati. I clienti si romperanno.
- Le nuove funzionalità non possono modificare le strutture di dati esistenti, pertanto i dati e le funzionalità vengono spesso separate artificialmente anche quando appartengono olisticamente a una funzione esistente.
- Il codice base diventa gradualmente più difficile da comprendere a causa della frammentazione, dei nomi confusi e del bagaglio residuo che non possono essere rimossi in modo sicuro.
- Tutti i cambiamenti, tranne che banali, diventano sempre più rischiosi e richiedono molto tempo.
- Il sistema ristagna e alla fine viene sostituito.
Don't expose your database structure directly to clients... especially clients you do not have developmental control over. Use an API to narrow the client down to just valid operations.
Quindi se stai usando un'API come un'interfaccia direttamente in un database, la pluralizzazione è l'ultima delle tue preoccupazioni. Per un esperimento diverso da quello a distanza, suggerirei di dedicare un po 'di tempo a determinare le operazioni di livello superiore che l'API dovrebbe rappresentare. E quando lo guardi in questo modo, non c'è conflitto tra nomi di entità API plurali e nomi di entità SQL singolari. Sono lì per diversi motivi.