Perché la convenzione dice che i nomi delle tabelle DB dovrebbero essere singolari ma risorse RESTful plurali?

È una convenzione piuttosto consolidata che i nomi delle tabelle del database, almeno in SQL, dovrebbero essere singolari. SELECT * FROM user;Vedi questa domanda e discussione .

È anche una convenzione piuttosto consolidata che i nomi delle risorse API RESTful dovrebbero essere plurali. GET /users/123e POST /usersvedi questo .

Nella più semplice API supportata da database, il nome della risorsa nell'URL sarebbe la tabella e gli elementi di dati nell'URL e nei corpi di richiesta / risposta verrebbero mappati direttamente alle colonne nel DB. Concettualmente, non vedo alcuna differenza tra il funzionamento dei dati tramite questa API teorica rispetto al funzionamento diretto tramite SQL. E per questo motivo, la differenza nelle convenzioni di denominazione tra usere usersnon ha senso per me.

Come può essere giustificata la differenza nella pluralizzazione quando, concettualmente, l'API REST e l'SQL stanno facendo la stessa cosa?

— smitelli
fonte

Non esiste una singola convenzione nella denominazione delle tabelle DB né nella denominazione delle risorse RESTful che tutti seguono. Al contrario, potrebbero esserci molte convenzioni. Non sorprende che alcuni possano scontrarsi.

— Eric King,

Non esiste una convenzione del genere. Ho sempre usato nomi di tabelle plurali. utenti , account , ecc., poiché detengono più di una di queste cose.

— GrandmasterB,

@GrandmasterB La convenzione esiste e ha origine nel modello relazionale di Codd in cui le "relazioni" (che diventano tabelle, non confondersi con le relazioni) hanno nomi singolari perché una relazione è un elenco di cose non diverse liste di cose. Ogni relazione è una lista. Entità di dominio del modello di relazioni. I nomi delle entità sono singolari nel modello relazionale di Codd. C'è abbondante letteratura a riguardo per dire che non esiste. Ma è perfettamente OK per te usare nomi plurali se vuoi.

— Tulains Córdova,

@ user61852 Ci sono persone che possono usarlo per convenzione. Ma non è affatto una convenzione di settore ampiamente seguita come presentata in questa domanda nel modo, diciamo, di CamelCase o MarkDown.

— GrandmasterB,

Inoltre, tenere presente che REST non è un protocollo di accesso al database. Non vi è alcun motivo per cui le convenzioni di denominazione dei DB (con cui si vada mai) e le convenzioni di denominazione degli URL (con quale si vada) devono essere simili, non hanno nulla a che fare l'una con l'altra. Due domini molto diversi. Non ha più senso riflettere sul motivo per cui i database usano singolare e gli URL usano il plurale che meditare sul perché i database usano un singolo, ma il mio amministratore di sistema chiama i suoi elenchi di file system al plurale. I framework Web progettati in modo inadeguato fanno pensare che REST abbia a che fare con l'accesso al database, ma non lo è.

— Cormac Mulhall,

Risposte:

Le specifiche REST (qualunque sia il livello che si desidera raggiungere) non sono state progettate come accesso al database. Sta cercando di portare la standardizzazione all'accesso alle API. Le convenzioni SQL menzionate (che tu voglia usarle o meno) non sono state progettate pensando all'accesso alle API. Sono per la scrittura di query SQL.

Quindi il problema da decomprimere qui è la comprensione concettuale che un'API esegue il mapping direttamente al database. Possiamo trovarlo descritto come un anti-pattern almeno fino al 2009 .

Il motivo principale è negativo? Il codice che descrive "in che modo questa operazione influisce sui miei dati?" diventa codice cliente .

Ciò ha effetti piuttosto terribili sull'API. (non un elenco esaustivo)

Rende difficile l'integrazione con l'API

Immagino i passaggi per creare un nuovo utente documentato come qualcosa del genere:

POST /users { .. }
POST /usersettings { .. } con alcuni valori predefiniti
POST /confirmemails { .. }

Ma come gestite un fallimento del passaggio 2? Quante volte questa stessa logica di gestione viene copiata e incollata ad altri client della tua API?

Queste operazioni sui dati sono spesso più facili da eseguire in sequenza sul lato server, mentre vengono avviate dal client come un'unica operazione. Es POST /newusersetup. I DBA possono riconoscere questo come una procedura memorizzata, ma l'operazione API può avere effetti oltre il solo database.

Proteggere l'API diventa un buco nero di disperazione

Supponiamo che tu debba unire due account utente.

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

Come hai intenzione di impostare un'autorizzazione utente per consentire la funzionalità di unione senza consentire l'eliminazione dell'utente? L'eliminazione di un utente è persino rappresentata in modo equo da DELETE /users/1quando /usersettingsesiste?

Le operazioni API devono essere considerate operazioni di livello superiore (rispetto al database) che possono causare più modifiche nel sistema.

La manutenzione diventa più difficile

... perché i tuoi clienti dipendono dalla struttura del tuo database.

Sulla base della 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 dati esistenti, quindi i suoi dati e funzionalità sono spesso separati artificialmente anche quando appartengono olisticamente a una funzionalità esistente.
La base di codice diventa gradualmente più difficile da comprendere a causa della frammentazione, dei nomi confusi e del bagaglio rimasto che non può essere rimosso in sicurezza.
Tutti i cambiamenti, tranne quelli banali, diventano sempre più rischiosi e richiedono molto tempo.
Il sistema ristagna e alla fine viene sostituito.

Non esporre la struttura del database direttamente ai client ... in particolare i client su cui non si ha il controllo dello sviluppo. Utilizzare un'API per restringere il client a sole operazioni valide.

Quindi, se stai usando un'API come semplice interfaccia direttamente in un database, la pluralizzazione è l'ultima delle tue preoccupazioni. Per un esperimento a parte, 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 pluralizzati e nomi di entità SQL singolari. Sono lì per diversi motivi.

— Kasey Speakman
fonte

Rispondi a una domanda diversa. OP non implica l'associazione diretta di entità API e DB, ma solo la presenza di alcune entità in entrambi i contesti.

— Basilevs,

Sentiti libero di pubblicare una risposta alla domanda che ritieni venga posta.

— Kasey Speakman,

@Basilevs In realtà penso che questo risponda alla domanda. A volte le risposte possono apparire indirette quando una domanda è incorniciata da ipotesi errate. La "presenza di alcune entità in entrambi i contesti" implica che sono le stesse entità, il che implica una corrispondenza 1 a 1 tra alcuni e non altri. Una tale corrispondenza di un'API su un modello di dati complesso implica una progettazione errata.

— Aluan Haddad,

Tra questi ci sono molti motivi per cui ho smesso di usare Spring Data Rest.

— Sebastiaan van den Broek,

L'API REST e l'SQL NON "fanno la stessa cosa"

L'OP chiede:

Come può essere giustificata la differenza nella pluralizzazione quando, concettualmente, l'API REST e l'SQL stanno facendo la stessa cosa?

Ah, ma cavalletta, può sembrare che l'interfaccia RESTful e le tabelle SQL "stiano facendo la stessa cosa", ma una buona igiene della programmazione ci dice che esiste sempre uno strato intermedio che media l'API REST e il database. Ignorare questo punto significa allontanarsi dal percorso verso l'illuminazione del software! :)

Quindi le API RESTful e le tabelle SQL possono felicemente seguire le proprie convenzioni di denominazione idiomatiche, che sono ben documentate e discusse approfonditamente altrove.

— fearless_fool
fonte