TL;DR
O WP-API é a nova aposta do WordPress. Atualmente, funciona como um plugin do WordPress, a ser incorporado em duas etapas no Core, que expõe o conteúdo em uma arquitetura REST dispondo-o em formato JSON, pronto para consumo em outras linguagens/sites/aplicações/aplicativos.
Índice
- Conceito
- O que o API significa para o WordPress?
- Se esse é o futuro, do que o WP-API é capaz?
- Ao expôr meu conteúdo, o WP-API não oferece nenhum risco à segurança?
- Como funciona o WP-API
- Instalando o plugin e fazendo sua primeira requisição
- Para obter uma lista de Posts
- Para visualizar um post específico
- Para obter uma lista de Páginas
- Para visualizar uma página especifica
- Requisitando uma Categoria ou tag de determinado post
- Obtendo uma lista de Categorias
- Lista de Tags
- Lidando e visualizando conteúdo com Custom Post Types
- Usando o ACF? Você ainda está na zona de conforto!
- Palavras finais
Conceito
Considerada a próxima grande aposta do WordPress (plataforma utilizada por ~25% dos sites em todo mundo), com a primeira fase prevista para a versão 4.4 em dezembro deste ano (2015) e integração total na versão 4.5, o WP-API (também conhecido como JSON API ou REST API) expõe as informações de um site feito em WordPress para que sites externos/aplicações/aplicativos consumam seus dados. Na data deste artigo, o WP-API está disponível como plugin e os desenvolvedores estão otimistas sobre a integração com o core do WP.
O WP-API foi criado para facilitar a interação de sites em WordPress com outros sites/aplicações. O API permite que outros serviços sejam integrados ao WordPress e abre a possiblidade para que os mesmos criem, leiam, atualizem e deletem seu conteúdo (CRUD), sem necessariamente terem uma instalação local do WordPress.
Antes que você questione: sem autenticação, apenas a leitura do conteúdo é possível. Mais abaixo
Imagine desenvolver seu blog em WordPress usando Rails? Django? Node? Java???
Quê cara, tá maluco? Que post é esse?
Essa realidade é possível porque a Web é feita de HTTP, que tem equivalentes CRUD com seus verbos POST, GET, PUT e DELETE, e o API é feito usando uma arquitetura REST.
No momento, desenvolver em WordPress requer algum conhecimento em PHP. Com o API, o PHP se tornará algo estritamente opcional, habilitando o desenvolvedor a utilizar seus conhecimentos em HTML, CSS e JavaScript/Ruby/Python/C#/FORTRAN (ok, forcei), o que for, para desenvolver seus temas, integrações, aplicações mobile e tudo o que a juventude de agora gosta de desenvolver. A saber: um API é uma porção de códigos que permite que outras aplicações acessem seus dados na web em uma forma mais simples (vide o API do YouTube, Facebook, Instagram e agora o WordPress).
Sendo um API RESTful, o WP-API permite que aplicações bem interessantes sejam criadas utilizando uma interface JSON.
O que o API significa para o WordPress?
VIDA. FUTURO. DOMINAÇÃO DO MERCADO. UM APLICATIVO DA SUA EMPRESA CONSUMINDO DATA DO SITE FEITO EM WORDPRESS.
O API evolui o WordPress como um CMS para uma aplicação completa. Veja: o API cria um padrão para que outras linguagens consigam interagir diretamente com seu conteúdo.
Se esse é o futuro, do que o WP-API é capaz?
Com a pretensão de usar a força da marca para incentivar desenvolvedores de outras linguagens a construir suas aplicações utilizando o WordPress, sejam elas plugins, temas, integrações, aplicações ou aplicativos, o WP-API amplifica o leque do WordPress à um nível inimáginável há alguns anos e talvez faça você perder seu preconceito. A ferramenta chega com as seguintes promessas:
Romper laços com o PHP
À parte da cultura da boca-torta criada no passado, o PHP ainda é a força-motriz por trás de 80% dos sites do mundo e tem o suporte de gigantes como Facebook, Wikipedia e o próprio WordPress. Entretanto, nos últimos anos houveram avanços significativos em linguagens como Ruby, Python, Go e claro, JavaScript, seja em termos de ferramentas, escalabilidade ou frameworks disponíveis.
O WP-API dá aos desenvolvedores dessas linguagens acesso imediato à todo o leque de funcionalidades do WordPress. Razão suficiente para captar a atenção dos desenvolvedores e proprietários de sites. Quando pensamos na grandiosidade do ecossistema do WordPress e nas possibilidades que os desenvolvedores tem de gerar receita com ele (sejam temas ou plugins), o potencial de portar sites inteiros feitos em WordPress para outras linguagens/plataformas é algo tentador em termos de experiência e, claro, receita.
Fazer uma integração mobile de verdade.
Com a popularização de frameworks como Foundation e Bootstrap, grande parte dos sites desenvolvidos nos últimos anos chegaram a um padrão aceitável em termos de visualização de conteúdo em dispositivos móveis, mas uma integração de verdade está longe de ser um padrão.
Estava.
Usando o WP-API, desenvolvedores mobile poderão lidar com sites em WordPress como lidariam com qualquer serviço de Mobile Back End as a Service (MBaaS ou BaaS). Este ponto sozinho já é suficiente para habilitar um site em WordPress como uma possibilidade para servir de backend para aplicações mobile nativas e serve de fundação para todos os tipos de integrações no futuro.
Quando considerada a quantidade de sites rodando WP, que têm uma versão completamente distinta de suas versões mobile, o escopo para integrações futuras é imenso. O ideal de ter um banco de dados e diversas aplicações consumindo suas informações, agora é possível de forma genuína e descomplicada.
Front-End modular
Do ponto de vista do API, o front-end do WordPress é só mais uma aplicação externa consumindo seus dados. Aplicações MVW (model, view, whatever) como AngularJS, EmberJS, MeteorJS, BackboneJS, poderão facilmente fazer suas requisições e montar o workflow dos seus sonhos sem se preocupar com as entrelinhas de desenvolvimento em WP.
A expectativa é ver uma revolução em plugins e temas para desenvolvedores e donos de site ao redor do mundo (são 25% da web, considere).
Back-End com a sua assinatura
A potencial integração do REST API no core abre a possibilidade de reimaginar o admin do WordPress. Imagine que todas as funcionalidades do core estão abertas à você, com nenhum visual para te limitar. Chega de editar cores e imagens para tentar deixar o admin “do seu jeito”, ou baixar o User Role Editor para proibir seus clientes de destruírem seu trabalho, ou usar uma função para injetar CSS com um “display: none” em coisas que você não gostaria que estivessem visíveis. Com o API, o controle é todo seu.
Mais um incentivo para você entrar na vibe do JavaScript e seguir a nova ordem mundial
Convenhamos: o JavaScript está criando uma nova ordem mundial. É hype, é futuro, é presente, opiniões divergentes. Em comum: é JavaScript. Frameworks MV** e outros menos conhecidos estão ditando uma tendência, que acredito seguir linear por um bom tempo.
O WP-API faz do WordPress um companheiro ideal para essas tecnologias. Na visão de desenvolvedor, poder utilizar tecnologias de vanguarda mantendo sua bagagem em WordPress, é o mundo ideal.
Ao expôr meu conteúdo, o WP-API não oferece nenhum risco à segurança?
Não. Não propriamente por conta do WP-API.
A informação que o API fornece é, naturalmente, o que um site WordPress dispõe por padrão publicamente. A única diferença entre o front-end de um site e o WP-API é a forma como as informações são apresentadas. Por padrão não é possível, sem autenticação, apagar, atualizar ou criar nada – apenas ler o conteúdo (requisição GET).
Claro que novas funcionalidades expõem novos riscos. Porém, por ora, nenhuma vulnerabilidade foi encontrada e manter seu WordPress atualizado é um método simples e confiável de se manter seguro.
Como funciona o WP-API
O WP-API é acessado por HTTP e retorna requisições em formato JSON. Ambos fáceis de utilizar e com grande suporte pelas linguagens de programação mais populares, através de bibliotecas como Net::HTTP (Ruby), Requests (Phyton) e GoReq (Go), para citar alguns.
Eu poderia me limitar a dizer que o WP-API é uma REST API, o que ficaria abstrato e não é o objetivo do artigo. O WP-API é empolgante, mas se você não tem nenhuma base sobre o que significa uma arquitetura REST, HTTP e requisições em geral, procurei expôr os conceitos mais básicos abaixo.
Antes de falar de REST, é necessário entender alguns conceitos de HTTP.
Um pouco de HTTP
Ele assina pelo nome de Hypertext Transfer Protocol (HTTP) e é um conjunto de regras que determina como informações podem ser enviadas e recebidas e quais mensagens devem ser retornadas em resposta às requisições.
Por exemplo, quando uma requisição é enviada pelo cliente e recebida com sucesso pelo servidor, a mensagem (conhecida como código de retorno, acompanhado de uma frase explicativa) é um variante de 200 (onde o número mais importante é a casa da centena, onde 2 significa sucesso na requisição). A mais famosa talvez seja a 404 – Not Found, que retorna um valor inexistente para sua requisição (onde o primeiro número quatro significa erro no cliente).
Outros protocolos bem conhecidos são o POP3 e o SMTP, que são usados para receber e enviar e-mails, respectivamente.
O HTTP tem duas funções distintas: servidor e cliente. Em geral, o cliente envia a requisição e o servidor responde. É feito basicamente do header (que contém metadata e informações importantes para o HTTP) e do body (que contém o conteúdo da mensagem).
Hypertext Transfer Protocol ou HTTP é a alma da web. É utilizado todas as vezes que você transfere um documento, ou faz uma solicitação AJAX.
Se quiser mais informações, o TutsPlus tem um ótimo tutorial, que usei como referência, com uma igualmente ótima tradução feita pelo Thierry Rene. Vale cada palavra.
Concordo com o autor do link de referência sobre o conhecimento de HTTP não ser comum entre desenvolvedores, o que também considero importante e recomendo a leitura.
O que significa REST?
REST é definido por Representational State Transfer! Entendi tudo, deixa eu dormir agora, obrigado.
Arquitetura: De acordo com uma citação do Wikipedia: a arquitetura lidaria com qualquer problema de agenciamento, organização, estética e ordenamento de componentes em qualquer situação de arranjo espacial.
Uma arquitetura REST é uma uma forma de organizar as interações entre sistemas. Ele define padrões, o que pode e o que não se deve fazer. A arquitetura fornece uma forma padronizada de como acessar dados. Em geral, sistemas seguem um padrão de comandos. Execute informação X, receba informação Y. Em uma arquitetura REST, o acesso é fornecido por recursos. O que significa que, em uma URL, tudo o que é passado são recursos que podem ser consumidos, não existem comandos inseridos e procura-se utilizar uma URL humanamente legível.
Exemplo de comando em uma URL.
Supondo que eu, ao acessar o site de minha empresa, gostaria de procurar por um vendedor admitido em 2015:
Repare na instrução ao servidor: busque por vendedores admitidos em 2015. Enquanto a instrução pode ser facilmente interpretada, equipe não é um recurso.
Se a requisição fosse feita em uma arquitetura REST, minha URL seria:
A URL, sem parâmetros, identifica o recurso que você deseja manipular de forma que eu obtenha informações precisas em todas as camadas. Fazer a requisição em um diretório retorna uma lista de recursos. Por exemplo, retirar “vendedor” da URL poderia me fornecer informações sobre todas as funções contratadas no ano de 2015.
Veja: a arquitetura não abomina o uso de parâmetros na URL, que podem ser utilizados como uma espécie de filtro ou outra forma conveniente.
Por fim, os sistemas que seguem os princípios REST são chamados de RESTFul.
API? é tipo… APP?
Não, não.
Um API (application programming interface) é uma forma simples de se comunicar com uma aplicação. Através de endpoints* definidos, os desenvolvedores podem fazer seus programas e scripts interagirem com a aplicação.
- Endpoints são definidos por suas funções, que podem ser acessados por HTTP. É a forma que o WP-API (que agora que você pegou a manha eu posso dizer: é um REST API) provê suas informações e permite seus desenvolvedores manipularem o WordPress, podendo ser a publicação de um post, atualização de uma página ou a exclusão de um comentário.
Certo, Cezar. Tudo isso parece mágico, linda teoria. Agora, como posso começar com o WP-API?
Instalando o plugin e fazendo sua primeira requisição
Os exemplos utilizados requerem a versão 2 do API. Para baixá-lo, vá ao repositório do WordPess: https://wordpress.org/plugins/rest-api/
Depois de baixado, basta fazer a instalação. A instalação ocorre da mesma forma que qualquer outro plugin do WordPress.
Visualizando o conteúdo like a boss ou A primeira requisição a gente nunca esquece
Se você usa o Chrome, baixe a extensão do Postman. O postman, dentre suas finalidades, vai servir para o propósito de visualizar o conteúdo da maneira correta.
Para todas as requisições que faremos, tome nota dessa instrução
Para visualizar sua primeira requisição, abra o Postman (você pode digitar o endereço no browser diretamente, se você não se importar com um monte de código chapado na tela) e digite na URL (válido para todos os exemplos abaixo):
Onde siteincrivel é o seu site e REQUISIÇÃO_AQUI será a requisição que vocẽ deseja fazer, dentre as possibilidades:
Para obter uma lista de Posts
Para visualizar um post específico
Onde {id} é o ID do Post que você precisa.
Para obter uma lista de Páginas
Para visualizar uma página especifica:
Onde {id} é o ID da página que você precisa.
Para visualizar uma lista de categorias ou tags
Categorias e Tags são consideradas taxonomias. As taxonomias, diferente de posts e páginas, funcionam pelo slug e não pelo ID. O ID é necessário apenas para chamadas de Posts/Páginas.
Os elementos de uma categoria ou tag, são consideradas pelo WordPress como termos (terms). Portanto ao criar a categoria Marketing, você está dizendo ao WordPress que a taxonomia Categoria tem um termo chamado Marketing.
Sendo assim:
Requisitando uma Categoria ou tag de determinado post:
Obtendo uma lista de Categorias
Nossa categoria modelo (Marketing) deverá aparecer aqui
Lista de Tags
Lidando e visualizando conteúdo com Custom Post Types:
Por padrão, o WP-API não autoriza a visualização direta de CPT. Para autorizar a requisição, abra o arquivo onde você armazena as informações sobre CPT do seu tema (em geral no functions.php, ou qualquer include que você tenha feito) e adicione o argumento (dentro de $args, por favor):
Caso você tenha feito corretamente, o endereço abaixo vai listar os posts relacionados àquele CPT:
Usando o ACF? Você ainda está na zona de conforto!
A integração com o ACF é extensa para o objetivo do post, o que não importa muito, pois existe um plugin excelente que cumpre a maioria das finalidades do ACF. Seja feliz.
Palavras finais
Vejo em muitos grupos e em alguns sites sobre o futuro do WordPress, que o sistema está em declínio e alguns absurdos também. O WP-API é uma grande aposta e suas promessas fazem merecer um olhar atento à nova funcionalidade.
Se quiser um modelo para começar, pode tentar o Picard, feito em ReactJS pela própria Automattic, ou se quiser uma ideia sobre mais possibilidades do API, o Make WordPress Core tem uma thread sobre aplicações que desenvolvedores estão trabalhando.
E você, tem alguma opinião a respeito? Desenvolveu alguma aplicação com o WP-API? Deixe um comentário, eu adoraria saber!
Referências:
- https://wp-api.org/
- https://feelingrestful.com/
- https://observer.com/2015/07/wordpress-rest-api/
- https://jacklenox.com/2015/03/30/building-themes-with-the-wp-rest-api-wordcamp-london-march-2015/
- https://torquemag.io/client-side-applications-powered-by-the-wordpress-json-rest-api/
- https://premium.wpmudev.org/blog/wordpress-rest-api/
- https://wpengine.com/blog/josh-pollock-wordpress-rest-api-finely-tuned-consultant/
- https://premium.wpmudev.org/blog/using-wordpress-rest-api/
- https://apppresser.com/wp-api-post-submission/
- https://blog.nexcess.net/2015/06/04/what-does-the-new-rest-api-mean-for-wordpress/
- https://melapress.com/wordpress-rest-api-and-the-security-worries/
- https://www.sitepoint.com/wp-api/
- https://1fix.io/blog/2015/07/20/query-vars-wp-api/
- https://code.tutsplus.com/tutorials/a-beginners-guide-to-http-and-rest–net-16340
- https://make.wordpress.org/core/2015/07/23/rest-api-whos-using-this-thing/