Backend HTTP – Criando uma simples API REST com APACHE e PHP

Introdução e Inicialização

Quando avançamos no desenvolvimento de plataformas, nos deparamos com o seguinte problema:

Como criar um backend confiável e segura para que os dados da minha plataforma possam ser acessados por uma interface web, aplicativo Android/iOS/etc, algoritmos automáticos e aplicações de terceiros, sem precisar criar várias vezes a mesma interface de acesso e de fácil manutenção?

Partindo desse problema, a W3C (World Wide Web Consortium) definiu o padrão REST como sendo:

A Representational State Transfer (REST), em português Transferência de Estado Representacional, é uma abstração da arquitetura da World Wide Web, mais precisamente, é um estilo arquitetural que consiste de um conjunto coordenado de restrições arquiteturais aplicadas a componentes, conectores e elementos de dados dentro de um sistema de hipermídia distribuído.

O REST ignora os detalhes da implementação de componente e a sintaxe de protocolo com o objetivo de focar nos papéis dos componentes, nas restrições sobre sua interação com outros componentes e na sua interpretação de elementos de dados significantes.

Em outras palavras, desenvolvemos um backend baseado no protocolo HTTP, que pode ser facilmente implementado utilizando servidores populares como o Apache ou NginX, em que as requisições e as URIs de acesso (chamaremos à partir daqui de endpoints), possuam formas como:

Para inserir um novo usuário ao sistema:

POST /usuario HTTP/1.1

Para obter um usuário de ID 3:

GET /usuario/3 HTTP/1.1

Para remover um usuário de ID 3:

DELETE /usuario/3 HTTP/1.1

E assim sucessivamente. Observe que talvez não seja possível definir qualquer ação somente com os métodos definidos pelo HTTP, o que nos leva à uma das características do REST: Ao contrário de outros padrões como o SOAP, que possuem endpoints “fixos”, o REST permite que o desenvolvedor possua a liberdade para descrever seus endpoints, dependendo apenas da experiência e do bom-senso do desenvolvedor para que se utilize nomes claros e objetivos, sem a utilização de Query Strings no endpoint para representar chaves primárias, somente em casos específicos para filtros de pesquisa. Alguns desenvolvedores também abominam a utilização de qualquer Query String, porém, para essa abordagem específica, utilizaremos para os critérios de busca.

Para os fins deste tutorial, presumiremos que o leitor já está familiarizado com a hospedagem de aplicações web desenvolvidas em PHP. Utilizaremos o servidor Apache com o mod-php5 para pré-processador, em um VirtualHost dedicado para hospedar nossa aplicação, com uma raiz exclusiva em uma subpasta da pasta /var/www, que chamaremos somente de raiz.

Em toda aplicação, gosto de utilizar uma classe singleton, cujas propriedades conterão as informações compartilhadas por toda parte da aplicação, a instância do PDO (assume-se também que o leitor esteja familiarizado em utilizar PDO ou outra classe como MySQLi para acesso ao banco de dados, que não precisa ser necessariamente o MySQL), e a instância do Roteador, que será tratado mais à frente.

Criaremos então o arquivo _global_config.php na raiz da nossa aplicação com o seguinte conteúdo:

 

Criaremos também o arquivo _machine_config.php para popular as configurações do arquivo anterior. Tal técnica é útil quando trabalhamos com múltiplas máquinas servindo a API, onde cada máquina pode ter algumas configurações diferentes. O conteúdo será o seguinte:

A propriedade API_ROOT_URL dirá qual é a raiz da sua aplicação. Se para acessar sua API, as requisições são feitas para http://exemplo.com/api/endpoint, a API_ROOT_URL será “/api”. Se as endpoints serão acessadas direto da raiz, como http://api.exemplo.com/endpoint, a API_ROOT_URL será a própria raiz: “/”.

Utilize os botões abaixo para navegar entre as sessões do post!

 

Comentários