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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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/
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/
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/
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/
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/
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/
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/
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/
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/
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/
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/
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/