Tutorial Laravel para iniciantes

O que é o Laravel?

Laravel é uma estrutura MVC da web de código aberto para PHP. Laravel é uma estrutura robusta que fornece fácil desenvolvimento de aplicações web PHP com recursos como um sistema de empacotamento modular com um gerenciador de dependências dedicado, acesso a bancos de dados relacionais e outros utilitários para implantação e manutenção de aplicações.

O Laravel foi criado por Taylor Otwell. Desde seu lançamento inicial em junho de 2011 (versão 1), ele tem crescido de forma constante e cada vez mais popular no setor de frameworks PHP da indústria de desenvolvimento web. Grande parte dessa popularidade pode ser atribuída aos muitos recursos voltados para desenvolvedores que ele oferece por padrão.

Por que Laravel?

Por volta de 2000, a maior parte Código PHP era processual e podia ser encontrado na forma de “scripts” que teriam uma confusão emaranhada de código espaguete. Mesmo as páginas mais simples não tinham separação de preocupaçõesAssim, era bastante fácil para uma aplicação se transformar rapidamente em um pesadelo de manutenção. O mundo precisava de algo melhor. Surgiram então o PHP versão 5 e uma variedade de frameworks PHP, que buscavam trazer a estrutura tão necessária e melhores soluções para diversas questões relacionadas a aplicações web.

Desde então, vimos o lançamento de muitos frameworks que pavimentaram o caminho para os frameworks populares usados ​​hoje. Atualmente, os três principais (na nossa opinião) são Zend Framework, Symfony e, claro, Laravel. Embora cada um desses frameworks tenha sido fundado em princípios semelhantes e seja voltado para a resolução (basicamente) dos mesmos problemas comuns, suas principais diferenças residem em suas implementações. Cada um tem suas próprias peculiaridades sobre como abordar a resolução de problemas. Ao analisar o código produzido por cada um deles, você perceberá que existe uma linha bastante clara que os separa. Na nossa humilde opinião, o framework Laravel é o melhor.

Saiba mais sobre o diferença entre Laravel e CodeIgnorar.

Como baixar e instalar o Laravel com Composer

Observação: Este tutorial foi escrito para o Laravel 5.8, mas os conceitos de roteamento, controlador, requisição e Blade permanecem os mesmos nas versões atuais. Em 2026, a versão mais recente é o Laravel 13 (lançado em março de 2026), que requer PHP 8.3 ou posterior, enquanto o Laravel 12 requer PHP 8.2.

Observação: Presume-se que você já tenha uma cópia do PHP instalada em seu sistema local. Caso contrário, você pode ler como instalá-la. aqui..

Composer é um gerenciador de pacotes e dependências. Para instalá-lo, abra um terminal e faça cd em um novo diretório. Execute este comando:

curl -Ss getcomposer.org/installer | php

Os resultados deste comando serão assim:

Observação: Para obter instruções mais detalhadas sobre como configurar o Laravel, consulte a documentação do Laravel. aqui..

Você verá o script composer.phar sendo baixado e compilado, que é o que usamos para instalar o Laravel. Embora existam várias maneiras de configurar um novo aplicativo Laravel, faremos isso usando o script composer do Laravel. Para instalar este script, execute:

composer global require laravel/installer

Que será parecido com isto:

Isso fará o download e a instalação de todos os arquivos do framework, bem como de todas as dependências necessárias. Os pacotes serão salvos no diretório vendor. Depois de baixados e instalados, basta executar o seguinte comando:

laravel new uploadApp

Você verá algo como a seguinte saída:

O Composer está instalando todos os pacotes que o Laravel precisa para funcionar. Isso pode levar alguns minutos, então tenha paciência. Após a conclusão, execute o comando `ls -al` para verificar o que foi instalado.

Aqui está uma breve análise dos diretórios em um aplicativo Laravel comum:

• aplicativo/ : Esta é a pasta de origem onde reside o código da nossa aplicação. Todos os controladores, políticas e modelos estão dentro desta pasta.
• inicialização/ : Contém o script de inicialização do aplicativo e alguns arquivos de mapa de classes.
• configuração/ : Contém os arquivos de configuração do aplicativo. Normalmente, esses arquivos não são modificados diretamente, mas dependem dos valores definidos no arquivo .env (ambiente) na raiz do aplicativo.
• base de dados/ : Armazena os arquivos do banco de dados, incluindo migrações, seeds e fábricas de teste.
• público/ : Pasta de acesso público contendo os arquivos compilados e, claro, um arquivo index.php.
• recursos/ : Contém recursos de front-end, como: JavaArquivos de script, arquivos de idioma, arquivos CSS/SASS e todos os modelos usados ​​no aplicativo (chamados de modelos Blade).
• rotas/ : Todas as rotas da aplicação estão dentro deste arquivo. Existem alguns "escopos" diferentes de rotas, mas o que abordaremos aqui é o arquivo web.php.
• armazenar/ : Todos os arquivos de cache temporários usados ​​pelo aplicativo, arquivos de sessão, scripts de visualização compilados e arquivos de log.
• testes/ : Contém arquivos de teste para o aplicativo, como testes unitários e testes funcionais.
• fornecedor/ : Todos os pacotes de dependência instalados com o Composer.

Agora, vamos construir o restante do aplicativo e executá-lo com um comando Artisan específico (para evitar o trabalho de instalar e configurar um servidor web como o Apache ou o Nginx). O arquivo .env contém todos os valores de configuração que os arquivos no diretório /config usam para configurar o aplicativo.

Design do aplicativo: um rápido resumo de nossos requisitos

Neste tutorial online do Laravel, estaremos construindo um aplicativo muito simples que fará apenas duas coisas:

1. lidar com uploads de arquivos de um formulário da web
2. Exibir os arquivos previamente carregados em uma página diferente.

Para este projeto, nossa aplicação será somente para escrita, o que significa que o usuário poderá apenas escrever arquivos e visualizar a lista de arquivos que carregou. Esta aplicação é extremamente básica, mas deve servir como um bom exercício para você começar a desenvolver suas habilidades e conhecimentos em Laravel. Observe que, por uma questão de brevidade, excluímos qualquer modelagem de banco de dados, migrações e autenticação, mas em uma aplicação real, esses são aspectos adicionais que você precisará considerar.

Aqui está uma lista de componentes que precisaremos para fazer o aplicativo funcionar conforme o esperado:

• A estrada Isso permitirá que o mundo externo (internet) utilize o aplicativo, além de especificar o ponto de extremidade que apontará para onde está localizada a lógica para salvar o arquivo carregado.
• A controlador que gerencia o fluxo de requisição para resposta.
• A modelo que será usado para exibir uma lista de arquivos enviados anteriormente e o próprio formulário de upload.
• A solicitar que o controlador usará para validar os dados passados ​​pelo formulário web.

O que é uma rota?

Uma rota no Laravel é basicamente um endpoint especificado por uma URI que funciona como um "ponteiro" para alguma funcionalidade oferecida pela aplicação. Normalmente, uma rota simplesmente aponta para um método em um controlador e também define quais métodos HTTP podem acessar essa URI. Uma rota não significa necessariamente um método de controlador; ela pode simplesmente delegar a execução da aplicação a um Closure definido ou a uma função anônima.

Por que usar uma rota?

As rotas são armazenadas em arquivos na pasta /routes dentro do diretório raiz do projeto. Por padrão, existem alguns arquivos diferentes correspondentes aos diferentes “lados” da aplicação (“lados” vem da metodologia de arquitetura hexagonal). Eles incluem:

• web.php: as rotas públicas baseadas no navegador. Estas são as mais comuns e são as que são acessadas pelo navegador web. Elas são executadas pelo grupo de middleware web e também contêm recursos para Proteção CSRF (o que ajuda a defender contra ataques maliciosos baseados em formulários) e geralmente contêm um certo grau de "estado" (com isso queremos dizer que utilizam sessões).
• api.php: rotas que correspondem a um grupo de API e, portanto, têm o middleware da API ativado por padrão. Essas rotas são sem estado e não possuem sessões ou memória entre requisições (uma requisição não compartilha dados ou memória com nenhuma outra requisição; cada uma é autoencapsulada).
• console.php: essas rotas correspondem a comandos artsan personalizados que você criou para seu aplicativo.
• channels.php: registra rotas para transmissão de eventos.

O arquivo principal com o qual devemos nos preocupar neste momento é o específico do navegador, web.php. Já existe uma rota definida por padrão, que é aquela que você acessa ao navegar para a raiz da web do seu aplicativo (a raiz da web está no diretório público). Precisaremos de três rotas diferentes para que nosso aplicativo de upload funcione:

• /upload: este será o URI da página principal que exibirá nosso formulário web para envio de arquivos.
• /process: este será o local para onde o formulário localizado no URI /upload enviará os dados submetidos (a "ação" do formulário).
• /list: este comando listará todos os arquivos enviados para o site.

Observação: O endpoint /list pode não ser necessário se quisermos colocar toda a lógica para exibir o formulário de upload e a lista de arquivos em uma única página; no entanto, mantivemos ambos separados por enquanto para adicionar um pouco mais de conteúdo ao assunto em questão.

//inside routes/web.php
Route::get('/upload', 'UploadController@upload')->name('upload');
Route::get('/download', 'UploadController@download')->name('download');
Route::post('/process', 'UploadController@process')->name('process');
Route::get('/list', 'UploadController@list')->name('list');

Neste tutorial do framework Laravel, para cada rota desejada, iremos listá-la explicitamente no arquivo de rotas web.php usando um dos métodos de requisição HTTP disponíveis (get(), post(), put(), delete(), patch() ou options()). Para uma descrição detalhada de cada um deles, consulte [link para a documentação]. esse O que esses métodos fazem é especificar quais verbos HTTP têm permissão para acessar uma determinada rota. Se você precisar que uma rota aceite mais de um verbo HTTP (o que pode acontecer se você estiver usando uma única página para exibir os dados iniciais e enviar os dados do formulário), você pode usar o método `Route::any()`.

O segundo argumento dos métodos `Route::get()` e `Route::post()` (e de qualquer outro método relacionado a verbos HTTP na fachada `Route`) é o nome de um controlador específico e o método contido nesse controlador que é executado ao acessar o endpoint da rota com a requisição HTTP permitida (GET, POST, PATCH, etc.). Estamos usando o `UploadController` para todas as rotas e as especificamos da seguinte forma:

O último método que chamamos em cada rota é a sua função `name()`, que aceita uma única string como argumento e é usada para, de certa forma, "etiquetar" uma rota específica com um nome fácil de lembrar (em nossos casos, `upload`, `process` e `list`). Pode não parecer um recurso tão importante dar a cada rota seu próprio nome quando... URL Tem exatamente o mesmo nome, mas é muito útil quando você tem uma rota específica como /users/profile/dashboard/config, que seria mais fácil de lembrar como profile-admin ou user-config.

Uma nota sobre fachadas:

• As fachadas fornecem uma interface "estática" para as classes disponíveis no contêiner de serviços da aplicação.
• Eles fornecem uma sintaxe concisa e memorável que permite usar os recursos do Laravel sem lembrar nomes longos de classes que devem ser injetados ou configurados manualmente.

Nas definições de rota acima, usamos o facade Route em vez de instanciar manualmente um novo objeto Illuminate/Routing/Router e chamar os métodos correspondentes nesse objeto. É apenas um atalho que economiza tempo.pingFacades são amplamente utilizadas em todo o framework Laravel; você pode e deve se familiarizar com elas. A documentação sobre Facades pode ser encontrada aqui. aqui..

O que é um Controlador?

Um controlador é o “C” na arquitetura “MVC” (Model-View-Controller), na qual o Laravel é baseado. O trabalho de um controlador pode ser resumido nesta definição simples: Ele recebe a solicitação do cliente e retorna uma resposta para o cliente. Esta é a definição básica e também o requisito mínimo de qualquer controlador. O que ele faz entre esses dois pontos é geralmente considerado a "ação" do controlador (ou a "implementação da rota"). Ele atua como o segundo ponto de entrada para a aplicação (o primeiro sendo a requisição) para o cliente, que envia a carga útil da requisição (que veremos a seguir) para a aplicação, esperando algum tipo de resposta (na forma de uma página de sucesso, redirecionamento, página de erro ou qualquer outro tipo de resposta HTTP).

Um controlador faz (basicamente) a mesma coisa que uma definição de rota, com uma função anônima definida como a "ação" quando essa rota é acessada. A diferença é que um controlador mantém bem a separação de responsabilidades, enquanto uma rota é definida diretamente no código da rota. URL definição, que basicamente significa que estamos acoplando o URI atribuído à rota com a implementação da rota, ou seja, o código que é executado quando essa rota é acessada.

Por exemplo, os dois trechos de código a seguir alcançarão a mesma coisa:

Exemplo #1: Definição e implementação de rota dentro de uma única chamada de método (no arquivo de rotas web.php)

//inside routes/web.php
<?php
Route::get('/hello-world', function(Request $request) {
$name = $request->name;
return response()->make("<h1>Hello World! This is ".$name, 200);
});

Exemplo nº 2: A definição da rota está dentro de routes/web.php, mas sua implementação reside dentro da classe /app/Http/Controllers/HelloWorldController.

//inside routes/web.php
<?php

Route::get('/hello-world', 'HelloWorldController@index')->name('hello-world');

------------------------------------------------------------------------------------
//inside app/Http/Controllers/HelloWorldController.php
<?php
namespace App\Http\Controllers;
use Illuminate\Http\Request;

class HelloWorldController extends Controller
{
public function index(Request $request)
{
$name = $request->name;
return response()->make("<h1>Hello World! This is ".$name, 200);
}
}

Embora o exemplo #2 do Laravel pareça dar muito mais trabalho (o que não é verdade, apenas um pouco mais de código), observe os benefícios que obtemos ao colocar nossa lógica de ação para a rota "hello-world" dentro de um controlador, em vez de na definição da rota como uma função de retorno de chamada:

1. Nossa lógica está claramente separada em sua própria classe (separação de responsabilidades).
2. Nosso controlador está configurado para ser estendido posteriormente, caso precisemos adicionar funcionalidades adicionais. Digamos que quiséssemos adicionar um recurso de "adeus, mundo". Nesse caso, renomearíamos o controlador para um nome mais genérico, como "HelloController", e definiríamos dois métodos separados. Olá() e adeus(). Também precisaríamos definir duas rotas separadas que mapeassem o /olá e / adeus URIs para seus respectivos métodos no controlador. Isso é preferível a sobrecarregar um arquivo de rotas com a implementação de cada rota definida como funções de retorno de chamada.
3. O Laravel tem a capacidade integrada de armazenar em cache todas as definições de rota no aplicativo para acelerar o tempo necessário para encontrar uma determinada rota (aumenta o desempenho do aplicativo); Contudo, Você só poderá aproveitar essa funcionalidade se todas as rotas definidas dentro do aplicativo estiverem configuradas usando um mapa específico do controlador.pings (veja o Exemplo nº 2 acima).

Vamos executar este comando que irá gerar um novo controlador para nós.

// ...inside the project's root directory:
php artisan make:controller UploadController

Basicamente, o que este comando faz é gerar um stub para um controlador chamado "UploadController" dentro do diretório principal de controladores em /app/Http/Controllers/UploadController.php. Sinta-se à vontade para abrir esse arquivo e dar uma olhada. É muito simples, pois é apenas uma versão stub do controlador, com o caminho de namespace correto e as classes necessárias das quais ele herda.

Gerando a solicitação

Antes de prosseguirmos neste tutorial de PHP Laravel e fazermos algumas alterações no stub gerado do UploadController, fará mais sentido criar primeiro a classe de requisição. Isso porque o método do controlador que lida com a requisição deve especificar o tipo do objeto de requisição em sua assinatura, permitindo que ele valide automaticamente os dados do formulário recebido (conforme especificado no método rules(); mais sobre isso adiante). Por enquanto, vamos usar o comando artisan novamente para gerar nosso stub de requisição:

php artisan make:request UploadFileRequest

Este comando irá gerar um arquivo chamado UploadFileRequest dentro de app/Http/Requests/UploadFileRequest. Abra o arquivo e dê uma olhada. Você verá que ele é muito simples, contendo apenas dois métodos: authorize() e rules().

Criando a lógica de validação

Vamos modificar o stub de requisição para atender às necessidades da nossa aplicação. Modifique o arquivo para que fique assim:

<?php

namespace App\Http\Requests;

use Illuminate\Foundation\Http\FormRequest;

class UploadFileRequest extends FormRequest
{
/**
* Determine if the user is authorized to make this request.
*
* @return bool
*/
public function authorize()
{
return true;
}

/**
* Get the validation rules that apply to the request.
*
* @return array
*/
public function rules()
{
return [
'fileName' => 'required|string',
'userFile' => 'required|file'
];
}
}

Não houve muitas mudanças, mas observe que o método `authorize()` agora retorna `true` em vez de `false`. Este método decide se a requisição deve ou não ser permitida no aplicativo. Se estiver definido como `false`, ele impede que a requisição entre no sistema. Este seria um local muito útil para implementar verificações de autorização do usuário ou qualquer outra lógica que determine se a requisição pode prosseguir para o controlador. Por enquanto, retornamos `true` para permitir que qualquer coisa utilize a requisição.

O outro método, rules(), é onde toda a mágica acontece em relação à validação. A ideia é simples: retornar um array contendo um conjunto de regras no formato de:

'formFieldName' => 'constraints this field has separated by pipe characters (|)'

Existem muitas restrições de validação diferentes que são suportadas pelo Laravel imediatamente. Para uma lista completa deles, verifique a documentação online aqui.Para nossa aplicação de upload, haverá dois campos que serão passados ​​via requisição POST de um formulário no front-end. O parâmetro `fileName` deve estar presente no corpo do formulário (ou seja, é obrigatório) e será usado como o nome do arquivo no armazenamento (isso é feito no controlador; falaremos sobre isso mais adiante). Também especificamos que o nome do arquivo deve ser uma string adicionando um caractere de barra vertical (|) e a palavra 'string'. As restrições são sempre delimitadas por barras verticais, permitindo que você especifique quaisquer critérios adicionais para o campo em questão em uma única linha.

O segundo parâmetro, userFile, é o arquivo que o usuário carrega através de um formulário em uma página da web. O parâmetro userFile também é obrigatório e devo ser um arquivo. Observação: Se esperássemos que o arquivo enviado fosse uma imagem, usaríamos a restrição de imagem, que limitaria os tipos de arquivo aceitos a um dos tipos de imagem mais populares (jpeg, png, bmp, gif ou svg). Como queremos permitir que o usuário envie qualquer tipo de arquivo, manteremos a restrição de validação de arquivo.

Isso resume praticamente tudo o que o objeto de requisição faz. Sua principal função é simplesmente armazenar o conjunto aceitável de critérios (restrições) que os parâmetros do corpo do formulário devem satisfazer para que o processo possa prosseguir na aplicação. Outro ponto importante é que esses dois campos (userFile e fileName) também devem ser especificados no código HTML como campos de entrada (com o nome do campo correspondendo ao nome dentro do objeto de requisição).

Você pode estar se perguntando: isso define as características do que uma solicitação de formulário deve conter, mas onde a verificação dessas restrições é feita de fato? Abordaremos isso a seguir.

Modificando o controlador

Abra app/Http/Controllers/UploadController e faça as seguintes alterações:

<?php

namespace App\Http\Controllers;

use Illuminate\Contracts\Container\BindingResolutionException;
use Illuminate\Http\Request;
use App\Http\Requests\UploadFileRequest; //our new request class
use Illuminate\Support\Facades\Storage;

class UploadController extends Controller
{
/**
* This is the method that will simply list all the files uploaded by name and provide a
* link to each one so they may be downloaded
*
* @param $request : A standard form request object
* @return \Illuminate\Contracts\View\Factory|\Illuminate\View\View
* @throws BindingResolutionException
*/
public function list(Request $request)
{
$uploads = Storage::allFiles('uploads');

return view('list', ['files' => $uploads]);
}

/**
* @param $file
* @return \Symfony\Component\HttpFoundation\BinaryFileResponse
* @throws BindingResolutionException
*/
public function download($file)
{
return response()->download(storage_path('app/'.$file));
}

/**
* @return \Illuminate\Contracts\View\Factory|\Illuminate\View\View
* @throws BindingResolutionException
*/
public function upload()
{
return view('upload');
}

/**
* This method will handle the file uploads. Notice that the parameter's typehint
* is the exact request class we generated in the last step. There is a reason for this!
*
* @param $request : The special form request for our upload application
* @return array|\Illuminate\Http\UploadedFile|\Illuminate\Http\UploadedFile[]|null
* @throws BindingResolutionException
*/
public function process(UploadFileRequest $request)
{
//At this point, the parameters passed into the $request (from form) are
//valid--they satisfy each of the conditions inside the rules() method

$filename = $request->fileName; //parameters have already been validated
$file = $request->file('userFile'); //so we don't need any additional isset()

$extension = $file->getClientOriginalExtension(); //grab the file extension
$saveAs = $filename . "." . $extension; //filename to save file under

$file->storeAs('uploads', $saveAs, 'local'); //save the file to local folder

return response()->json(['success' => true]); //return a success message
}
}

Portanto, é uma abordagem bastante simples para salvar os arquivos enviados no disco. Aqui está uma descrição detalhada do método process() acima:

• Indique o tipo da classe de requisição no método do controlador que executa a funcionalidade principal, para que possamos validar automaticamente os dados recebidos.
• Obtenha o arquivo do objeto de requisição (agora validado) dentro do método do controlador.
• Extraia o nome do arquivo da requisição.
• Gere o nome do arquivo final que será usado para salvar o arquivo. O método getClientOriginalExtension() simplesmente captura a extensão original do arquivo carregado.
• Armazene o arquivo no sistema de arquivos local usando seu método storeAs(), passando o caminho nomeado dentro do diretório /storage como o primeiro argumento e o nome do arquivo para salvá-lo como o segundo.
• Retorna uma resposta JSON indicando que a solicitação foi bem-sucedida.

O modelo de lâmina

A última peça fundamental deste quebra-cabeça é o modelo Blade, que conterá todo o HTML, CSS e JavaScript para nossa aplicação simples. Aqui está o código; explicaremos mais tarde.

<body>
<h1>Upload a file</h1>
<form id="uploadForm" name="uploadForm" action="{{route('process')}}" enctype="multipart/form-data">
@csrf
<label for="fileName">File Name:</label>
<input type="text" name="fileName" id="fileName" required /><br />
<label for="userFile">Select a File</label>
<input type="file" name="userFile" id="userFile" required />
<button type="submit" name="submit">Submit</button>
</form>
<h2 id="success" style="color:green;display:none">Successfully uploaded file</h2>
<h2 id="error" style="color:red;display:none">Error Submitting File</h2>
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js"></script>
<script>
$('#uploadForm').on('submit', function(e) {
e.preventDefault();
var form = $(this);
var url = form.attr('action');
$.ajax({
url: url,
type: "POST",
data: new FormData(this),
processData: false,
contentType: false,
dataType: "JSON",
success: function(data) {
$("#fileName").val("");
$("#userFile").val("");
}
}).done(function() {
$('#success').css('display', 'block');
window.setTimeout(()=>($("#success").css('display', 'none')), 5000);
}).fail(function() {
$('#error').css('display', 'block');
window.setTimeout(()=>($("#error").css('display', 'none')), 5000);
});
});
</script>
</body>
</html>

Aqui está o que nosso / Envio página parece com:

Este é um exemplo muito típico de um arquivo blade contendo um formulário HTML e JavaScript/jQuery para adicionar funcionalidade assíncrona (para que a página não seja recarregada). Existe um básico. tag sem atributo method (que explicaremos em breve) e com um curioso atributo action com o valor {{route('process')}}. Em Blade, isso é conhecido como um Directiva. Uma diretiva é apenas um nome sofisticado para uma função; são funções específicas dos templates Blade que executam diferentes operações comuns à construção de páginas e aplicações web. Para um melhor entendimento de todas as funcionalidades úteis do Blade, consulte a documentação. aqui.No caso acima, estamos usando a diretiva de rota para gerar um URL para o envio do nosso formulário.

Lembre-se de que definimos nossas rotas anteriormente no arquivo web.php da aplicação, especificando um nome fácil de lembrar para cada uma delas. A diretiva {{route()}} aceita o nome de uma rota, a busca na lista de rotas armazenada em cache internamente e gera uma rota completa. URL com base na definição dessa rota no arquivo web.php. Para este primeiro caso, estamos especificando que queremos que o formulário envie os dados submetidos para /process. URL da nossa aplicação, que é definida como uma POST rota.

A próxima coisa que você pode ter notado é a tag `@csrf` logo abaixo da tag de abertura do formulário. No Blade, essa tag gera um parâmetro `_token` no formulário, que é verificado internamente pela aplicação antes que os dados do formulário possam ser processados. Isso garante que os dados dentro do formulário sejam de origem válida e previne ataques de falsificação de requisição entre sites (CSRF). Para mais informações sobre isso, consulte a documentação. docs.

Depois disso, definimos nosso formulário normalmente; no entanto, observe que os nomes dos nossos parâmetros de formulário, userFile e fileName, são os mesmos. exatamente o mesmo conforme definido dentro do nosso objeto de requisição. Se nos esquecêssemos de incluir um valor para um determinado parâmetro definido no objeto de requisição (ou o digitássemos incorretamente), a requisição falharia e um erro seria retornado, impedindo que a requisição original do formulário chegasse ao método do controlador localizado em UploadController@process.

Experimente e envie alguns arquivos para o aplicativo usando este formulário. Depois, acesse o /Lista página para ver o conteúdo da pasta de upload, com os arquivos que você enviou listados em uma tabela:

The Bigger Picture

Vamos dar um passo atrás e analisar o que fizemos neste tutorial de Laravel.

Este diagrama representa a aplicação em seu estado atual (excluindo detalhes de alto nível):

Você deve se lembrar que o objeto de requisição que construímos no início deste tutorial de Laravel deve ter os mesmos parâmetros definidos em seu método `rules` que os parâmetros do formulário no template Blade (caso contrário, releia a seção “Criando a Lógica de Validação”). O usuário preenche o formulário em uma página web renderizada pelo mecanismo de templates Blade e o envia. O código jQuery do template, na parte inferior, impede o envio padrão (que redirecionaria automaticamente para uma página separada), cria uma requisição AJAX, carrega a requisição com os dados do formulário e o arquivo enviado e envia tudo para a primeira camada da nossa aplicação: a requisição.

O objeto de requisição é preenchido associando os parâmetros dentro do método `rules()` com os parâmetros do formulário submetido e, em seguida, valida os dados de acordo com cada regra especificada. Se todas as regras forem satisfeitas, a requisição é encaminhada para o método do controlador correspondente aos valores definidos no arquivo de rotas `web.php`. Neste caso, é o método `process()` do `UploadController` que realiza o trabalho. Ao chegarmos ao controlador, já sabemos que a requisição passou pela validação, portanto, não precisamos verificar novamente se o nome do arquivo fornecido é, de fato, uma string ou se o parâmetro `userFile` realmente contém algum tipo de arquivo. Podemos prosseguir normalmente.

O método do controlador extrai os parâmetros validados do objeto de requisição, gera um nome de arquivo completo concatenando o parâmetro `fileName` passado com a extensão original do arquivo do usuário, armazena o arquivo em um diretório da aplicação e retorna uma resposta simples codificada em JSON, confirmando o sucesso da requisição. A resposta é recebida pela lógica do jQuery, que executa algumas tarefas adicionais relacionadas à interface do usuário, como exibir a mensagem de sucesso (ou erro) por 5 segundos e, em seguida, ocultá-la, além de limpar os campos anteriores do formulário. Isso garante ao usuário que a requisição foi bem-sucedida e permite o envio de outro arquivo, se desejar.

Observe também no diagrama acima exatamente onde a linha divisória entre o cliente e o servidor é traçada. Esse conceito é absolutamente crucial para você entender e ajudará a resolver problemas e dificuldades que possam surgir no futuro ao lidar, por exemplo, com múltiplas requisições assíncronas que podem ocorrer a qualquer momento. A separação ocorre exatamente no limite do objeto de requisição. O próprio objeto de requisição pode ser considerado o "portal" para o restante da aplicação. Ele realiza a validação inicial e o registro dos valores do formulário enviados pelo navegador. Se forem considerados válidos, a requisição segue para o controlador. Tudo o que acontece antes disso ocorre no front-end (o "cliente" significa literalmente "no computador do usuário"). A resposta é retornada da aplicação para o lado do cliente, onde nosso código jQuery aguarda pacientemente sua chegada e executa algumas tarefas simples de interface do usuário assim que a recebe.

Também abordamos muitas perguntas frequentes importantes. Perguntas da entrevista relacionadas ao Laravel e PHP para calouros e também para candidatos experientes conseguirem o emprego certo.

Perguntas Frequentes