WordPress Como Um Backend De Seus Aplicativos

Discutiremos a possibilidade de usar o WordPress como um servidor para alimentar conteúdo para aplicativos móveis e armazenar as informações geradas pelos usuários destes.
Para isso, ferramentas disponíveis no ecossistema serão analisadas, ambas oferecidas pelo CMS (API REST, autenticação, banco de dados ...) e geradas pela comunidade ou por nós mesmos (plugins).
Serão estudados quais pontos essenciais dos quais um MBaaS (Mobile Backend como Serviço) deve cobrir WordPress e serão ponderados as ocasiões em que usá-lo com relação a outras soluções do mercado mais comum.

Transcript

1. WordPress como um backend de seus aplicativos III - Conferência PHPRS
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_APIs
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_APIs
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
51. Alguma pergunta ? Onde me chamar: ◉ @jacksonfdam ◉ jacksonfdam[at]gmail.com Obrigado! 51