Definir a estrutura inicial de dados em Laravel API é o primeiro passo para construir uma base sólida antes de programar endpoints. Aqui vais aprender a criar tabelas, migrações e relações one-to-many e many-to-many aplicando boas práticas que funcionam em qualquer framework profissional.

Que versões e ferramentas precisas para começar?

Antes de gerar o projeto, confirma que o teu ambiente está alinhado com as versões recomendadas. Isto evita conflitos durante a instalação e ao correr migrações.

• Instalador do Laravel atualizado [0:25].
• PHP 8.2.6 ou superior [0:30].
• Composer 2.5.7 ou superior [0:35].
• MariaDB como base de dados, embora o Laravel seja flexível com outras tecnologias [0:42].

O projeto começa com o comando laravel new laravel-api dentro da tua pasta de sites [1:10]. A partir daí, todo o trabalho acontece no terminal integrado do Visual Studio Code.

O que é uma migração no Laravel? É um ficheiro PHP que descreve a estrutura de uma tabela e permite versionar a base de dados. Cada migração pode ser executada ou revertida com um comando.

Como gerar modelos, fábricas e migrações com Artisan?

O comando php artisan make:model é o ponto de partida. Combinado com flags adicionais, cria simultaneamente o modelo, a factory e a migração correspondente, poupando passos manuais [2:30].

Neste projeto, vais criar três entidades centrais:

• Category, que agrupa receitas.
• Recipe, a entidade principal de cozinha.
• Tag, que permite etiquetar receitas com múltiplos elementos.

A decisão de modelar assim responde a uma necessidade clara: uma categoria contém várias receitas (relação one-to-many) e uma receita pode ter várias etiquetas (relação many-to-many) [3:15]. Esta combinação cobre os dois cenários mais comuns em qualquer API real.

Que campos precisa cada tabela?

A migração de categories precisa apenas de um campo name do tipo string além dos campos automáticos id, created_at e updated_at [4:00]. A tabela de tags segue exatamente a mesma estrutura.

A migração de recipes é mais rica porque carrega o peso das relações e do conteúdo:

• category_id como unsignedInteger com chave estrangeira referenciando categories.id [4:45].
• user_id com chave estrangeira para users.id, ambos com onDelete cascade [5:30].
• title do tipo string.
• description do tipo text.
• ingredients e instructions para o conteúdo da receita.
• image como campo opcional, já que vais carregar imagens via API [6:10].

O efeito cascade garante que, ao eliminar uma categoria ou utilizador, as receitas associadas desaparecem automaticamente. É uma forma de manter a integridade referencial sem registos órfãos.

Como criar a tabela pivot para relações muitos-para-muitos?

Quando duas entidades se relacionam em many-to-many, precisas de uma tabela intermediária chamada pivot. No Laravel existe uma convenção de nomenclatura que deves respeitar para que o framework reconheça a relação automaticamente.

O comando é php artisan make:migration create_recipe_tag_table [7:20]. Repara em dois detalhes da convenção:

• Os nomes das entidades vão no singular, ao contrário das tabelas normais que vão no plural.
• A ordem é alfabética: recipe antes de tag.

Por que a tabela pivot usa nomes no singular? Porque o Laravel infere o nome a partir dos modelos relacionados, que sempre são singulares. Quebrar esta regra obriga-te a configurar a relação manualmente.

Dentro desta migração registas dois campos: recipe_id e tag_id, ambos como chaves estrangeiras com cascade. Os campos created_at e updated_at são eliminados porque numa tabela pivot raramente fazem sentido [8:40].

Por que usar onDelete cascade nas relações?

O cascade propaga a eliminação. Se apagas um utilizador, todas as receitas dele somem. Se apagas uma receita, as ligações na tabela pivot também desaparecem. Sem isto, ficavas com dados inconsistentes a ocupar espaço e a quebrar consultas.

Que conceitos de modelagem deves dominar?

A estrutura criada cobre os fundamentos que vais reencontrar em qualquer framework profissional, seja Django, Rails ou Spring. Os pilares são:

• Migrações versionadas para controlar mudanças no schema.
• Modelos que representam entidades do domínio.
• Factories para gerar dados de teste de forma rápida.
• Chaves estrangeiras com regras de integridade como cascade.
• Tabelas pivot com convenções de nomenclatura claras.

O resultado final são quatro migrações que formam a base do projeto: categories, recipes, tags e recipe_tag. A partir daqui, qualquer endpoint que construas vai apoiar-se nesta fundação.

Pratica este exercício no teu próprio ambiente e conta nos comentários se estás a usar outro framework. A lógica de relações e migrações replica-se em todos eles, só muda a sintaxe.