Na parte 1 deste guia, eu dei uma olhada na API HTTP em geral. Aprendemos o que é HTTP, falamos sobre a estrutura das solicitações e respostas HTTP e como os tipos de ação e URLs se unem para determinar o que você recebe em troca de sua solicitação. Neste post, vamos dar uma olhada na API HTTP do WordPress.
O WordPress HTTP API
Desde da versão 2.7 o WordPress tem uma API para lidar com HTTP. Ela é composta de 9 funções, das quais você provavelmente só usará um casal. As funções podem ser arquivadas em dois grupos distintos – um para fazer solicitações, outro para ler resultados.
wp_remote_get(), wp_remote_post(), wp_remote_head() usam os métodos GET, POST e HEAD respectivamente para solicitar dados de uma determinada URL. A função wp_remote_request() é uma função geral que permite especificar uma URL e um método para acompanhá-la.
As funções usadas para a leitura das respostas são descritas de forma semelhante. wp_remote_retrieve_body() recebe o corpo da resposta, a função wp_remote_retrieve_header() recebe um cabeçalho nomeado. A função wp_remote_retrieve_headers() retorna todos os cabeçalhos em forma de array, wp_remote_retrieve_response_code() fornece o código de resposta e wp_remote_retrieve_response_message() retorna a mensagem de resposta.
Isso é basicamente tudo o que existe, tudo o que precisamos saber é como especificar cabeçalhos para fazer os pedidos adequados.
Fazendo pedidos
Vamos usar a função wp_remote_get() para fazer um pedido. Vamos usar o primeiro parâmetro para definir a URL e o segundo para adicionar argumentos. Você pode encontrar o conjunto completo de parâmetros suportados no The Codex, vou me concentrar nas informações de cabeçalho aqui.
Para obter uma mensagem de status do usuário no Twitter, você precisará usar o caminho statuses/user_timeline.json junto com a URL https://api.twitter.com/1.1 e passar um token portador para autenticação – que eu gerei anteriormente. O token portador precisa ser adicionado como um cabeçalho de autorização na forma de Bearer [TOKEN].
$token = 'Sijbwrf82wdaBief';
$response = wp_remote_get('https://api.twitter.com/1.1/statuses/user_timeline.json?screen_name=kinsta', array(
'headers' => array(
'Authorization' => 'Bearer ' . $token
),
));Fazendo este pedido devolve uma riqueza de informações que podem ser obtidas através da impressão da variável $response. Você também pode usar as funções do tipo wp_remote_retrieve para obter uma parte da resposta.
Na maioria das vezes, o corpo contém as informações necessárias, geralmente no formato JSON. Em PHP, podemos converter isso em uma matriz com facilidade:
$data = json_decode( $response['body'], true ) Acesso ao Github API
Vamos construir um exemplo rápido que listará nosso mais recente repos Github em um widget WordPress. Primeiro, você precisará entrar no Github e ir para seu perfil, editá-lo e ir para “tokens de acesso pessoal” onde você pode gerar um token.
Como próximo passo, vamos criar um modelo de widget vazio. Este widget terá duas opções: um lugar para você adicionar seu token API e um título. Este não é o melhor método, pois salva seu token no banco de dados, mas é bom para nossos propósitos de exemplo.
class My_Github_Widget extends WP_Widget {
public function __construct() {
parent::__construct(
'my_github_widget',
'My Github Repos',
array( 'description' => 'A widget that showcases your Github repos' )
);
}
public function widget( $args, $instance ) {
// Widget output
}
public function form( $instance ) {
$token = ! empty( $instance['token'] ) ? $instance['token'] : '';
$title = ! empty( $instance['title'] ) ? $instance['title'] : 'From Github';
?><label for="get_field_id( 'title' ); ?>">Title <input class="widefat" id="get_field_id( 'title' ); ?>" name="get_field_name( 'title' ); ?>" type="text" value="">
<label for="get_field_id( 'token' ); ?>">Github API Token <input class="widefat" id="get_field_id( 'token' ); ?>" name="get_field_name( 'token' ); ?>" type="text" value="">
<?php } }Não quero me aprofundar muito na forma como os widgets são criados aqui. Se você quiser saber mais, dê uma olhada no guia Widgets API no Codex. A parte importante é que o conteúdo do método widget() produzirá o conteúdo de nosso widget. Dentro dessa função, vamos nos conectar ao Github usando uma solicitação HTTP e depois formatar e emitir a resposta. Eis como tudo isso é feito – todo o código a seguir vai para o método widget().
echo $args['before_widget'];
if ( ! empty( $instance['title'] ) ) {
echo $args['before_title'] . apply_filters( 'widget_title', $instance['title'] ). $args['after_title'];
}
$args = array(
'headers' => array(
'Accept' => 'application/vnd.github.v3+json',
'Authorization' => 'token 3f4f654ab31c2f15e839c74c952e5de2f562f1ee'
)
);
$response = wp_remote_get( 'https://api.github.com/user/repos', $args );
$repos = json_decode( $response['body'], true );
if( !empty( $repos ) ) {
echo '<ul>';
foreach( $repos as $repo ) {
echo '<li><a href="' . $repo['url'] . '" target="_blank">' . $repo['name'] . '</a></li>';
}
echo '</ul>';
}
echo $args['after_widget'];Ele começa com a simples adição do elemento e título do invólucro do widget na parte superior e termina fechando o invólucro do widget, a seção principal do código fica entre os dois.
Primeiro montei meus cabeçalhos de solicitação HTTP. A primeira pergunta pode ser: como posso saber quais parâmetros acrescentar? O cabeçalho Authorization é a parte mais importante, li isso na seção Authentication dos documentos da API.
O cabeçalho Accept não é necessário, mas no topo da mesma página do documento o guia o encoraja a fornecer isto.
Em seguida, uso json_decode() no corpo da resposta e simplesmente percorro a matriz resultante, criando uma lista de links.
Próximos passos
Se você acha que isso foi fácil, está totalmente certo! A parte difícil é garantir que você tenha todos os ângulos cobertos sem desperdiçar recursos. Há duas questões com o código que exigiriam nossa atenção imediata.
Se houver algum problema com o API – que pode incluir erros desconhecidos, contas com taxas limitadas e assim por diante – podemos nos deparar com um grande erro. Estamos apenas verificando se o corpo está vazio ou não antes de mostrarmos a lista.
Se tivermos um erro em nossas mãos, é provável que o corpo contenha informações de erro, portanto, também não estaria vazio neste caso. É provável que listaríamos os elementos da resposta ao erro, mas como estes não teriam url e propriedades de name, acabaríamos com elementos de lista vazia e avisos PHP.
A segunda questão é que isto é apenas um desperdício. Estamos nos conectando a um serviço externo em cada carregamento de página que pode ter um custo em nossos servidores e pode fazer com que a conta seja limitada no Github. Mesmo que este não seja o caso, qual a probabilidade de sua lista de reporte Github mudar entre duas visualizações de página, e qual a importância de ter até a segunda informação aqui?
Eu recomendaria pessoalmente o uso de transientes em um caso como este. Um transiente permite armazenar a resposta do pedido com um tempo de expiração. Se você definir a expiração para um dia, os dados serão recuperados do Github uma vez, então diretamente de seu banco de dados durante as próximas 24 horas. Após a expiração, os dados são recuperados novamente do Github e salvos no banco de dados.
Isto reduz suas chamadas API de uma por página para uma por dia, o que é uma enorme melhoria e também não é uma grande mudança.
Resumo
O WordPress facilita a interação com APIs de toda a web. O uso de um par de funções integradas permitirá que você obtenha dados mais ricos e mais relevantes para seus usuários.
Juntamente com a sanitização, verificação de erros e um mecanismo de cache você pode construir uma aplicação eficiente que não só é mais útil, mas que consome menos recursos do que você poderia imaginar.
Se você usou o WordPress HTTP API para conectar o WordPress com um terceiro API nos avise, seria ótimo ouvir sobre seu trabalho!
Oi, meu nome é Daniel, sou o CTO aqui na Kinsta. Você talvez me conheça da Smashing Magazine, WPMU Dev, Tuts+ e outras revistas de WordPress/Desenvolvimento. Além de WordPress e PHP, passo a maior parte do meu tempo com Node, React, GraphQL e outras tecnologias no espaço Javascript. Quando não estou trabalhando para criar a melhor solução de hospedagem do universo, coleciono jogos de tabuleiro, jogo pebolim no escritório, viajo ou toco guitarra e canto em uma banda não muito boa.
Deixe um comentário