Por que a convenção diz que os nomes de tabelas do banco de dados devem ser singulares, mas os recursos RESTful do plural?

É uma convenção bastante estabelecida que nomes de tabelas de banco de dados, pelo menos em SQL, devem ser singulares. SELECT * FROM user;Veja esta pergunta e discussão .

Também é uma convenção bastante estabelecida que os nomes de recursos da API RESTful devem ser plurais. GET /users/123e POST /usersveja este .

Na API mais simples suportada pelo banco de dados, o nome do recurso na URL seria a tabela, e os elementos de dados na URL e nos corpos de solicitação / resposta seriam mapeados diretamente para as colunas no banco de dados. Conceitualmente, não vejo diferença entre operar nos dados através desta API teórica e operar diretamente através do SQL. E por isso, a diferença nas convenções de nomenclatura entre usere usersnão faz sentido para mim.

Como a diferença de pluralização pode ser justificada quando, conceitualmente, a API REST e o SQL estão fazendo a mesma coisa?

— smitelli
fonte

Não existe uma convenção única na nomeação de tabelas do banco de dados nem na nomeação de recursos RESTful que todos seguem. Pelo contrário, pode haver muitas convenções. Não é de surpreender que alguns possam entrar em conflito.

— Eric King

Não existe uma convenção estabelecida. Eu sempre usei nomes de tabelas plurais. usuários , contas etc., pois eles estão mantendo mais de uma dessas coisas.

— GrandmasterB

@GrandmasterB A convenção existe e tem sua origem no modelo relacional de Codd, em que "relações" (que se tornam tabelas, para não confundir com relações) têm nomes singulares, porque uma relação é uma lista de coisas e não várias listas de coisas. Cada relação é uma lista. Entidades de domínio do modelo de relações. Os nomes das entidades são singulares no modelo relacional do Codd. Há literatura abundante sobre o assunto, dizendo que ele não existe. Mas é perfeitamente aceitável que você use nomes no plural, se quiser.

— Tulains Córdova

@ user61852 Há pessoas que podem usá-lo por convenção. Mas não é de forma alguma uma convenção amplamente seguida pela indústria, como apresentada nesta pergunta, por exemplo, como camelCase ou MarkDown.

— GrandmasterB

Lembre-se também de que o REST não é um protocolo de acesso ao banco de dados. Não há razão para que as convenções de nomenclatura de banco de dados (com qual você vá) e as convenções de nomenclatura de URL (com qualquer que você vá) sejam iguais, elas não têm nada a ver uma com a outra. Dois domínios muito diferentes. Não faz mais sentido ponderar por que os bancos de dados usam singular e URLs usa o plural do que ponderar por que os bancos de dados usam único, mas meu administrador de sistemas nomeia seus diretórios de sistema de arquivos no plural. Estruturas da web mal projetadas fazem as pessoas pensarem que REST é algo relacionado ao acesso ao banco de dados, mas não é.

— Cormac Mulhall

Respostas:

A especificação REST (qualquer que seja o nível que você queira ir) não foi projetada como acesso ao banco de dados. Ele está tentando trazer padronização para o acesso à API. As convenções SQL mencionadas (se você deseja usá-las ou não) não foram projetadas com o acesso à API em mente. Eles são para escrever consultas SQL.

Portanto, o problema a ser descompactado aqui é o entendimento conceitual de que uma API mapeia diretamente para o banco de dados. Podemos encontrar isso descrito como um anti-padrão pelo menos desde 2009 .

A principal razão pela qual isso é ruim? O código que descreve "como essa operação afeta meus dados?" torna-se código de cliente .

Isso tem alguns efeitos terríveis na API. (não é uma lista exaustiva)

Torna difícil a integração com a API

Eu imagino as etapas para criar um novo usuário documentado da seguinte forma:

POST /users { .. }
POST /usersettings { .. } com alguns valores padrão
POST /confirmemails { .. }

Mas como você lida com uma falha da etapa 2? Quantas vezes essa mesma lógica de manipulação é copiada em massa para outros clientes da sua API?

Essas operações de dados geralmente são mais fáceis de sequenciar no lado do servidor, enquanto são iniciadas no cliente como uma única operação. Por exemplo POST /newusersetup. Os DBAs podem reconhecer isso como um procedimento armazenado, mas a operação da API pode ter efeitos além do banco de dados.

Proteger a API se torna um buraco negro de desespero

Digamos que você precise mesclar duas contas de usuário.

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

Como você irá configurar uma permissão de usuário para permitir o recurso de mesclagem sem permitir a exclusão do usuário? A exclusão de um usuário é representada de maneira justa por DELETE /users/1quando /usersettingstambém existe?

As operações da API devem ser encaradas como operações de nível superior (que não o banco de dados), que podem causar várias alterações no sistema.

Manutenção fica mais difícil

... porque seus clientes dependem da sua estrutura de banco de dados.

Com base na minha experiência com este cenário:

Você não pode renomear ou remover tabelas / colunas existentes. Mesmo quando eles são nomeados incorretamente por sua função ou não são mais usados. Clientes vão quebrar.
Os novos recursos não podem alterar as estruturas de dados existentes; portanto, seus dados e funcionalidade geralmente são separados artificialmente, mesmo quando pertencem holisticamente a um recurso existente.
A base de código gradualmente se torna mais difícil de entender devido à fragmentação, nomes confusos e bagagem restante que não pode ser removida com segurança.
Todas, exceto as triviais, tornam-se cada vez mais arriscadas e demoradas.
O sistema estagna e é substituído.

Não exponha sua estrutura de banco de dados diretamente a clientes ... especialmente clientes sobre os quais você não tem controle de desenvolvimento. Use uma API para restringir o cliente a apenas operações válidas.

Portanto, se você estiver usando uma API apenas como uma interface direta em um banco de dados, a pluralização é a menor das suas preocupações. Para outras experiências que não sejam descartáveis, sugiro que dedique algum tempo a determinar as operações de nível superior que a API deve representar. E quando você olha dessa maneira, não há conflito entre nomes de entidades da API pluralizados e nomes de entidades SQL singulares. Eles estão lá por diferentes razões.

— Kasey Speakman
fonte

Responde a uma pergunta diferente. O OP não implica a associação direta de entidades API e DB, apenas a presença de algumas entidades nos dois contextos.

— Basilevs

Sinta-se à vontade para postar uma resposta à pergunta que você acha que está sendo feita.

— Kasey Speakman 03/02

@Basilevs Na verdade, acho que isso responde à pergunta. Às vezes, as respostas podem parecer indiretas quando uma pergunta é enquadrada em torno de suposições incorretas. A "presença de algumas entidades nos dois contextos" implica que são as mesmas entidades, o que implica uma correspondência de 1 para 1 entre algumas e outras não. Essa correspondência de uma API sobre um modelo de dados complexo implica um design defeituoso.

— Aluan Haddad

Entre essas muitas razões, parei de usar o Spring Data Rest.

— Sebastiaan van den Broek

A API REST e o SQL NÃO estão "fazendo a mesma coisa"

O PO pergunta:

Como a diferença de pluralização pode ser justificada quando, conceitualmente, a API REST e o SQL estão fazendo a mesma coisa?

Ah, mas gafanhoto, pode parecer que a interface RESTful e as tabelas SQL "estão fazendo a mesma coisa", mas uma boa higiene de programação nos diz que sempre há uma camada intermediária que medeia entre a API REST e o banco de dados. Ignorar esse ponto é desviar-se do caminho para a iluminação do software! :)

Portanto, as APIs RESTful e as tabelas SQL podem seguir alegremente suas próprias convenções de nomenclatura idiomática, que são bem documentadas e discutidas em outros lugares.

— fearless_fool
fonte