Um dos objetivos deste blog é me auxiliar no processo de aprendizado do Slim, e um recurso que realmente me atrai no slim é a maneira como ele trata as rotas, é um mecanismo bem simples de se implementar, se tornando uma ferramenta bem poderosa quando você o compreende.
Todo desenvolvedor web sabe como funciona o protocolo HTTP (ou pelo menos deveria saber). Então vamos a uma pequena introdução sobre ele para tentar cobrir os aspectos que nos interessam.
Um pouquinho da história
Hypertext Transfer Protocol (HTTP) é o método utilizado para enviar e receber informações na internet. O protocolo é definido pela especificação RFC 2616 ( da versão 1.1). Vamos ser sinceros, é grande, é uma leitura massante, são informações estruturais como esta que vão fazer a diferença entre um usador de scripts e um desenvolvedor de verdade.Como funciona?
O protocolo HTTP é baseado em requisições e respostas entre clientes e servidores. O cliente — navegador ou dispositivo que fará a requisição; também é conhecido como user agent — solicita um determinado recurso (resource), enviando um pacote de informações contendo alguns cabeçalhos (headers) a um URI ou, mais especificamente, URL. O servidor recebe estas informações e envia uma resposta, que pode ser um recurso ou um simplesmente um outro cabeçalho.Eu fiz uma solicitação aqui pro meu blog, usando o Google Chrome, abaixo esta a chamada que foi feita ao servidor web:
Vamos analizar o cabeçalho:
- As linhas 1 e 2 mostra o tipo de solicitação que foi realizada, o método GET, e a versão do http que estamos utilizando (no caso a 1.1), e o a url requisitada;
- A linha 4 mostra quais os formatos de retorno aceitáveis pelo agente (no meu caso o agente é o Google Chrome em um Mac OS exibido na linha 5);
Agora um exemplo de como obter um array com estas informações no slim:
<?php
$app = new \Slim\Slim();
$app->get('/',function () use ($app){
$headers = $app->request->headers;
print_r($headers);
});
$app->run();
De posse destas informações você pode realizar os tratamentos necessários, e as customizações necessárias para o output de seu código.
O cabeçalho da resposta a solicitação GET é o seguinte:
Reparem o código 200 de status logo na primeira linha (conheça todos os códigos de status clicando aqui), seguida das informações do conteúdo (utilizadas na renderização pelo brownser, e que você poderia utilizar no seu cliente) na segunda linha.
Compreender o cabeçalho permitirá a você extender muito suas aplicações, especialmente quando estiver construindo um serviço REST, no momento de criar autenticações, chaves personalizadas, retornos especificos, etc.
O protocolo HTTP é stateless, ou seja, ele não é capaz por si só de reter informações entre requisições diferentes. Ou seja(2) cada requisição que é feita ao servidor web é uma nova requisição, e ela não armazena as informações da requisição anterior.
Para persistir informações você utilizar cookies, sessões, campos de formulário ou variáveis na própria URL.
Pra deixar isso mais claro pra você como os cookies funcionam : quando você usa a instrução PHP pra criar um cookie, ele é gerado no agente e depois disso em todas as solicitações ele será incluído no cabeçalho http , permitindo que você trabalhe com esta informação.
Status
Toda requisição recebe um código de resposta conhecido como status. Com o status é possível saber se uma operação foi realizada com sucesso (200), se ele foi movida e agora existe em outro lugar (301) ou se não existe mais (404).Existem muitos status divididos em diversas categorias. Na especificação você pode ver cada um deles com uma descrição bastante detalhada. Se você quiser ver todos os códigos clique aqui.
Vou adicionais aqui, os que você provavelmente usará no desenvolvimento da sua aplicação:
| Cod. | Nome | Descrição |
|---|---|---|
| 200 | OK | Indica que uma requisição foi feita com sucesso. |
| 201 | Created | Indica que uma requisição foi feita com sucesso e que um recurso foi criado. Normalmente utilizamos esse padrão de resposta para POST e PUT. |
| 400 | Bad Request | Infica que uma requisição não possuí um formato especifico. Normalmente utilizada quando alguma validação de dados não passa, ou quando esta faltando algum dado ou até mesmo um formato errado. Muito comum utilizar como erro de retorno para POST e PUT. |
| 401 | Unauthorized | Indica que o recurso ou endpoint precisa de um requisição autenticada antes de proseguir. |
| 404 | Not Found | Indica que o recurso da requisição não existe. Normalmente utilizado quando um endpoint não corresponde com nenhuma rota registrada na aplicação. |
| 405 | Method Not Allowed | Indica que o método HTTP utilizado não esta disponível para aquele endpoint. |
| 409 | Conflict | Indica que um conflito ocorreu durante a requisição. Por exemplo, isso poderia ocorrer quando você utiliza PUT para atualizar o mesmo registro com dados duplicado, pode não ser um exemplo muito bom, mas não tenho nada melhor em mente. |
| 422 | Unprocessable Entity | Indica que a request foi realizada e entendida pelo servidor, porem não foi possível proceguir devido a erros no formato/parâmetros informados. Por exemplo, o erro pode ser lançado caso você espere um XML como parâmetro mas ao invés disso o cliente envia um JSON, ou em um caso mais simplificado poreriam ser valores obrigatórios em um JSON que não correspondem com um modelo/validação. |
| 500 | Internal Server Error | Indica uma falha do lado servidor, normalmente utilizamos quando algo inesperado acontece do lado servidor. |
