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!
Hi, my name is Daniel, I'm the CTO here at Kinsta. You may know me from Smashing Magazine, WPMU Dev, Tuts+ and other WordPress/Development magazines. Aside from WordPress and PHP I spend most of my time around Node, React, GraphQL and other technologies in the Javascript space.
When not working on making the best hosting solution in the Universe I collect board games, play table football in the office, travel or play guitar and sing in a pretty bad band.
Deixe um comentário