O documento fornece uma introdução sobre como usar o WordPress como um backend para aplicativos, discutindo APIs do WordPress como a REST API e HTTP API. Ele explica conceitos-chave como rotas, solicitações, respostas e esquemas e como eles se aplicam à REST API do WordPress.

1. WordPress como um
backend de seus
aplicativos

2. Eu sou o Jackson Mafra
Desenvolvedor há mais de 20 anos com background em
projetos de e-commerce e mercado imobiliário, desde 2009
com interesses focados para o desenvolvimento de
interfaces móveis e aplicações corporativas.
@jacksonfdam
Olá!
2

3. Diferença entre
Web Services e API
Por que todos os tigres são gatos, mas nem todos os gatos são tigres.
1
3

4. Web Services vs API
4

5. API (Application
Programming Interface)
É como uma interface entre dois programas diferentes de modo
que eles possam se comunicar um com o outro.
Ou seja, uma API é a forma que terceiros disponibilizam uma
interface de modo que possamos consumir um determinado
serviço deles sem nos preocuparmos com a implementação do
mesmo.
As API podem usar qualquer meio de comunicação para iniciar a
interação entre as aplicações.
Por exemplo, as chamadas de sistema (System Calls) são
invocados usando interrupções da API do kernel Linux.
5

6. Web Services
É uma interface projetada para se comunicar via rede.
É uma API que usa obrigatoriamente a rede.
Tipicamente, HTTP é o protocolo mais comumente usado para a
comunicação.
Web Services também usam SOAP, REST e XML-RPC como meio
de comunicação.
Ou seja, quando uma API precisa enviar dados através de rede,
estamos falando de Web Services.
6

7. Resumindo
◉ Todos os Web Services são API. Mas nem todas as API são Web Service.
◉ Web Services podem não executar todas as tarefas que uma API
normalmente realiza (ou pode realizar).
◉ Um serviço Web utiliza apenas três estilos de comunicação: SOAP, REST
e XML-RPC enquanto que a API pode usar qualquer estilo de
comunicação.
◉ Um Web Service sempre precisa de uma rede para o seu funcionamento
enquanto uma API não precisa.
◉ Uma API facilita a interface direta com um aplicativo enquanto que um
Web Service é uma aplicação.
7

8. CORS
CORB e CORP.
8

9. “
Quem aí já teve problemas com
CORS?
Mais fácil perguntar quem nunca
teve, né?
9

10. Cross-Origin Resource
Sharing
CORS é o acrônimo de Cross-Origin Resource Sharing, que por sua vez, é
uma especificação que visa criar um ambiente lógico de segurança no que diz
respeito ao modo que consumimos conteúdo da web via browsers.
Mas além de CORS, existem algumas outras abordagens que adicionam
camadas extras de segurança na forma em que o browser se comunica com
os servidores.
A proposta principal do CORS é que ao receber uma requisição do browser, o
servidor responderá uma informação via HTTP header, e tal informação,
definirá exatamente como o browser validará a origem da requisição.
10

11. Cross-Origin Resource
Sharing
Por exemplo, supondo que um servidor aceite requisições apenas do domínio
meusite.com, o servidor precisará simplesmente responder suas requisições
com o header Access-Control-Allow-Origin e o valor http://meusite.com
para habilitar o CORS no browser com essa regra.
11

12. Cross-Origin Resource
Sharing
Há também a possibilidade de informar para o browser que qualquer origem
pode acessar determinados recursos ou todos os recursos de um servidor. E
para isso basta utilizar o valor * no header Access-Control-Allow-Origin
globalmente ou em requisições específicas.
12

13. Cross-Origin Resource
Sharing
Recomendo o post "Política de Cross-Origin" da Ana Coimbra.
Tem bastante informação sobre o assunto lá.
13

14. Cross-Origin Read Blocking
Valida requisições do browser antes mesmo de serem requisitadas no
servidor. Tudo isso utilizando o MIME type da requisição como regra de
validação.
Por exemplo, uma requisição do tipo style deve fornecer o MIME type
text/css, caso contrário, será bloqueada.
14

15. Cross-Origin Read Blocking
Para habilitar este recurso, o servidor deve enviar sempre o header X-
Content-Type-Options com o valor nosniff.
Essa proposta visa ajudar na segurança contra ataques maliciosos do tipo
CSRF, Meltdown e Spectre.
15

16. Cross-Origin Resource Policy
Ele é um complemento ao CORB e só funciona para requisições definidas
como no-cors, ou seja, requisições explicitamente sem proteção garantida de
CORS.
16

17. Cross-Origin Resource Policy
Para habilitar esse cross-origin checker, o servidor deve enviar o header
Cross-Origin-Resource-Policy com o valor same-origin ou same-site.
17

18. Cross-Origin Resource Policy
Com este header declarado pelo servidor, o browser irá invalidar
respectivamente requisições no-cors de domínios com origem ou esquema
de url diferente da origem da requisição.
E como a CORB, essa proposta também visa ajudar contra ataques maliciosos
do tipo Meltdown e Spectre.
18

19. Resumindo
Vale lembrar que estas soluções são efetivas, mas não perfeitas, pois acessos
inesperados e maliciosos ao servidor também podem ser feito através de
browsers antigos (inseguros) que não suportam CORS, CORB e/ou CORP e
também via terminais.
Sendo assim, seu servidor deve ser autossuficiente contra acessos
indesejados.
19

20. WP-API
REST API != WordPress APIs != API HTTP
20

21. APIs WordPress
21

22. WordPress
APIs
As APIs do WordPress representa a Interface de Programação de Aplicativos
do WordPress.
Podem ser separadas em várias seções / tópicos da API.
Cada um abrange as funções envolvidas e uso de um determinado conjunto
de funcionalidades.
Juntos, eles formam o que pode ser chamado de WordPress API, que são as
interfaces plugin / tema / add-on criadas por todo o projeto WordPress.
22
https://codex.wordpress.org/WordPress_API
s

23. WordPress APIs
◉ Dashboard Widgets API
◉ Database API
◉ HTTP API
◉ REST API
◉ File Header API
◉ Filesystem API
◉ Metadata API
◉ Options API
◉ Plugin API
◉ Quicktags API
23
◉ Rewrite API
◉ Settings API
◉ Shortcode API
◉ Theme Modification API
◉ Theme Customization API
◉ Transients API
◉ Widgets API
https://codex.wordpress.org/WordPress_API
s

24. API HTTP
24

25. API HTTP
Dentro do PHP, existem muitas maneiras possíveis de enviar solicitações
HTTP.
Os exemplos incluem file_get_contents, fsockopen e cURL.
Antes do WordPress 2.7, todos os desenvolvedores de plug-ins tinham sua
própria implementação para enviar solicitações HTTP e receber a resposta, o
que era um fardo adicional para eles, porque precisavam dar suporte
posteriormente para mantê-los funcionando.
25
https://codex.wordpress.org/HTTP_API

26. API HTTP
A API HTTP do WordPress foi criada para padronizar uma única API que
tratava de tudo o que era relacionado ao HTTP da maneira mais simples
possível.
A API HTTP suporta vários transportes HTTP ou implementações para atender
diferentes ambientes e configurações de hospedagem.
26
https://codex.wordpress.org/HTTP_API

27. API HTTP
A API HTTP fornece uma interface unificada usando um punhado de funções
auxiliares.
HTTP é centrado em torno de métodos (às vezes chamados de verbos) e
recursos.
Os recursos definem o item em que você deseja realizar uma ação específica
, o método define o tipo de ação que deseja realizar.
Um recurso é uma URL que aponta para um objeto na web, por exemplo,
uma publicação. Há uma série de métodos , os mais importantes dos quais
são GET, POST, PUT e DELETE.
27
https://codex.wordpress.org/HTTP_API

28. API HTTP
Existem quatro funções para fazer pedidos com:
◉ wp_remote_get()
◉ wp_remote_post()
◉ wp_remote_head()
◉ wp_remote_request()
Estes são bastante auto-explicativos, o último wp_remote_request(), é uma
função generalizada que você pode usar com qualquer verbo HTTP.
28
https://codex.wordpress.org/HTTP_API

29. API HTTP
Para recuperar as diferentes partes da resposta e também testar qualquer
erro resultante, a API HTTP do WordPress fornece as seguintes funções
auxiliares:
◉ wp_remote_retrieve_body () - Recupera apenas o corpo da resposta.
◉ wp_remote_retrieve_headers () - Retorna uma matriz de todos os
cabeçalhos HTTP de resposta.
◉ wp_remote_retrieve_header () - Retorna o valor de um cabeçalho HTTP
com base no nome fornecido.
◉ wp_remote_retrieve_response_code () - Retorna os códigos de status de
resposta da solicitação HTTP.
29
https://codex.wordpress.org/HTTP_API

30. API REST
30

31. REST API
Ela foi essencialmente projetada para preencher a lacuna entre o núcleo PHP
do WordPress e o JavaScript que muitos aplicativos da Web usam
atualmente.
A infraestrutura para a API REST do WordPress foi adicionada ao núcleo do
WordPress na versão 4.4 (codinome “Clifford”) em dezembro de 2015.
Você precisava de um plug-in para usar a API REST naquele momento.
No entanto, o restante dessa API, os endpoints de conteúdo para serem
exatos, foi adicionado ao núcleo do WordPress na versão 4.7 (codinome
“Vaughan”) em dezembro de 2016, negando a necessidade do plugin WP
REST API.
31
https://developer.wordpress.org/rest-api/

32. WordPress roadmap
32

33. REST API
Todo o seu conteúdo é disponibilizado em consultas rápidas de texto que são
entregues via JSON, com ela você pode consultar o texto de um artigo, os
links das imagens que ele carrega, autor, comentários, pode trabalhar com
resultados de busca, tudo que você faz em seu painel pode ser
disponibilizado para consultas remotas e integrações com outros sistemas.
Tudo funciona através de chamadas como /wp-json/wp/v2/posts, /wp-
json/wp/v2/users/4, /wp-json/wp/v2/posts?filter[s]=suporte, você pode
consultar a documentação completa para mais parâmetros.
33
https://developer.wordpress.org/rest-api/

34. “
Todo o seu conteúdo é
disponibilizado em consultas
rápidas de texto que são entregues
via JSON
34

35. REST API
Como uma API pode te ajudar? 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.
35
https://developer.wordpress.org/rest-api/

36. “
Ao expôr meu conteúdo, o WP-API não
oferece nenhum risco à segurança?
Não.
Não propriamente por conta da WP-
API.
36

37. REST API
A informação que a 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.
37
https://developer.wordpress.org/rest-api/

38. REST API
Para começar a usar a API REST do WordPress, vamos detalhar alguns dos
principais conceitos e termos associados à API:
◉ Routes/Endpoints
◉ Requests
◉ Responses
◉ Schema
◉ Controller Classes
38
https://developer.wordpress.org/rest-api/

39. REST API
Routes & Endpoints
Uma rota, no contexto da API REST do WordPress, é um URI que pode ser
mapeado para diferentes métodos HTTP.
O mapeamento de um método HTTP individual para uma rota é conhecido
como um “endpoint”. Se fizermos uma solicitação GET para/wp-json/ ,
obteremos uma resposta JSON mostrando-nos quais rotas estão disponíveis
e, dentro de cada rota, quais terminais estão disponíveis. /wp-json/ é uma
rota em si e quando uma solicitação GET é feita, ela corresponde ao terminal
que exibe o que é conhecido como o índice da API REST do WordPress.
39
https://developer.wordpress.org/rest-api/

40. 40
REST API
https://developer.wordpress.org/rest-api/

41. Se você estiver usando permalinks (urls amigáveis), passe a rota da API REST
como um parâmetro de string de consulta.
A rota /wp-json/ seria /?rest_route=/ .
41

42. REST API
Requests
Uma das classes principais na infraestrutura da API REST do WordPress é
WP_REST_Request .
Essa classe é usada para armazenar e recuperar informações para a
solicitação atual; Os requests podem ser enviados remotamente via HTTP,
mas também podem ser feitos internamente a partir do PHP com o
WordPress.
Os objetos WP_REST_Request são gerados automaticamente para você
sempre que você faz uma solicitação HTTP para uma rota registrada.
42
https://developer.wordpress.org/rest-api/

43. REST API
Responses
Respostas são os dados que você recebe da API.
A classe WP_REST_Response fornece uma maneira de interagir com os
dados de resposta retornados pelos nós de extremidade.
As respostas podem retornar os dados desejados e também podem ser
usadas para retornar erros.
43
https://developer.wordpress.org/rest-api/

44. REST API
Schema
Cada endpoint requer e fornece estruturas de dados ligeiramente diferentes,
e essas estruturas são definidas no esquema da API.
O esquema estrutura os dados da API e fornece uma lista abrangente de
todas as propriedades que a API pode retornar e parâmetros de entrada que
pode aceitar.
O esquema também fornece benefícios de segurança para a API, pois nos
permite validar as solicitações feitas à API.
44
https://developer.wordpress.org/rest-api/

45. REST API
Controller Classes
Como você pode ver, a API REST do WordPress tem muitas partes móveis
que precisam trabalhar juntas.
As classes do controlador reúnem todos esses elementos em um único lugar.
Com uma classe de controlador, você pode gerenciar o registro de rotas e
terminais, manipular solicitações, utilizar o esquema e gerar respostas da API.
45
https://developer.wordpress.org/rest-api/

46. Pagination
Qualquer resposta da API que
contenha vários recursos
suporta vários parâmetros de
consulta comuns para manipular
a paginação pelos dados da
resposta
Autenticação
A autenticação de cookie é o único
mecanismo de autenticação
disponível nativamente no
WordPress, os plug-ins podem ser
adicionados para oferecer suporte
a modos alternativos de
autenticação que funcionarão a
partir de aplicativos remotos.
46
REST API
https://developer.wordpress.org/rest-api/

47. REST API
FAQ - Posso desativar a API REST?
Você não deve desabilitar a API REST, pois isso quebrará a funcionalidade
Admin do WordPress que depende da API estar ativa.
No entanto, você pode usar um filtro para exigir que os consumidores da API
sejam autenticados, o que efetivamente impede o acesso externo anônimo.
47
https://developer.wordpress.org/rest-api/

48. WordPress Plugins
◉ Advanced Custom Fields
◉ ACF to REST API
◉ JWT Authentication for WP REST API
◉ Custom Post Type UI
◉ Basic-Auth
48

49. Repositório utilizado:
https://github.com/jacksonfdam/wp-baas
49

50. 50

51. Alguma pergunta ?
Onde me chamar:
◉ @jacksonfdam
◉ jacksonfdam[at]gmail.com
Obrigado!
51