Como remover rotas e pontos de extremidade da API REST padrão do WordPress

A API REST do WordPress foi introduzida no núcleo na versão 4.7 (Vaughan) em dezembro de 2016. Como qualquer outra mudança significativa feita no núcleo do WP, foi muito debatida (no momento, julho de 2018, Gutenberg é o assunto de tal debate/ controvérsia). No final, nada aconteceu. Aqueles que não se importavam com a API REST ainda não se importam. Quem se importa fez alguns aplicativos, integrações, plugins e outros projetos legais.

E enquanto estamos no tema de projetos legais. Você sabia que os mais bem-sucedidos começam com uma página em breve? E em muitos casos, é uma página em breve que foi construída usando o plug-in Coming Soon & Maintenance Mode.

Este plugin vem com um construtor de arrastar e soltar, mais de 170 temas, a melhor configuração de SEO da categoria, serviços de resposta automática e e-mail e muitos outros recursos que permitirão que você crie a página perfeita em breve em minutos. Além de tudo isso, o plug-in é integrado ao Depositphotos, o que significa que você pode encontrar os melhores recursos visuais diretamente do plug-in. Mas caso você não seja fã das ofertas da coleção Depositphotos, o Yay Images também é uma ótima fonte de conteúdo de estoque.

Mas chega de falar nisso, vamos voltar ao nosso tópico principal, API REST.

Nós nos preocupamos com a API REST e a utilizamos ao construir SaaS com tecnologia WP. É estável, rápido, fácil de trabalhar, encaixa perfeitamente no WP e, na maioria dos casos, bem documentado. Se você não sabe o que é REST API, este provavelmente não é o post para você, mas confira o que é REST API (vídeo e texto) e talvez você a use em seu próximo projeto.

Rota? Ponto final? Não é tudo igual?

Não, não é o mesmo. A diferença é sutil para a maioria das pessoas, e eles usam os termos rota e ponto final de forma intercambiável, mas não é tão complicado. A rota é mais ou menos a URL. É o “nome” usado para acessar um endpoint. Em uma única rota, você pode ter vários endpoints porque o endpoint que você usa depende do tipo de solicitação HTTP que você usa. GET , POST , PUT ou DELETE podem, e geralmente servem a propósitos diferentes. Acessando yoursite.com/wp-json/v2/posts/1 via GET você obterá detalhes para postagem com ID #1. Usar DELETE na mesma rota chamará um endpoint diferente (ou função, se você quiser) que exclui essa postagem. O manual oficial da API REST tem mais informações sobre esse assunto, então mergulhe para mais detalhes.

Por que eu removeria os endpoints ou rotas padrão da WP REST API?

Como discutimos no artigo sobre como remover regras de reescrita padrão – existem centenas de razões pelas quais um desenvolvedor do WordPress faria isso.
“Isso tornará o WordPress mais rápido porque não precisa analisar todos esses endpoints.” ainda é algo com o qual não concordo e acredito que o ganho será inferior a um milissegundo, mas não pode doer.

Você gosta de manter as coisas limpas e como você não está usando a API REST – por que ter rotas de API? Claro, faz sentido. Mas nesse caso, use um plugin para desabilitar completamente a API REST.

E então há a razão pela qual desabilitamos as rotas padrão (e endpoints). Usamos muito os endpoints personalizados da API REST, mas não precisamos dos padrão. Portanto, é bom manter as coisas enxutas e limpas. Também não pode prejudicar a segurança, pois estamos expondo menos dados ao mundo exterior hostil.

Mostre-me os endpoints de API padrão

A referência de endpoint está disponível no manual da API REST. Mais ou menos qualquer parte dos dados disponíveis publicamente também estará disponível por meio da API REST. Um exemplo de solicitação para demo.wp-api.org/wp-json/wp/v2/posts mostrará dez postagens no formato JSON. Se você quiser uma versão legível dessa resposta, precisará decodificar a resposta JSON. O mesmo vale para páginas, categorias e outras estruturas de dados. A estrutura de dados e os endpoints são muito semelhantes, como você pode ver se navegar pela referência.

A outra maneira de ver as rotas padrão é adicionar este código ao arquivo functions.php do seu tema e então abrir yoursite.com/wp-json/. Habilite links bonitos se ainda não tiver feito isso.

add_filter( 'rest_endpoints', 'show_default_endpoints' );
 
function show_default_endpoints( $endpoints ) { 
  var_export( array_keys( $endpoints ) );
  die;
}

Ele mostra os 31 terminais REST padrão. O número é, obviamente, suscetível a mudanças à medida que novas funcionalidades principais são adicionadas. E será diferente se você tiver algum plug-in que adicione endpoints personalizados.

Removendo os endpoints padrão

O código acima requer alterações mínimas. Retorne uma matriz vazia e todos os endpoints desaparecerão.

add_filter( 'rest_endpoints', 'remove_default_endpoints' );
 
function remove_default_endpoints( $endpoints ) { 
  return array( );
}

"Todos os endpoints" também inclui seus endpoints personalizados, portanto, é aconselhável não excluí-los. Aqui está uma maneira fácil de mantê-los ativos:

add_filter( 'rest_endpoints', 'remove_default_endpoints_smarter' );
 
function remove_default_endpoints_smarter( $endpoints ) { 
  $prefix = 'your_custom_endpoint_prefix';

  foreach ( $endpoints as $endpoint => $details ) {
    if ( !fnmatch( '/' . $prefix . '/*', $endpoint, FNM_CASEFOLD ) ) {
      unset( $endpoints[$endpoint] );
    }
  }

  return $endpoints;
}

Basta pular os endpoints com seu prefixo personalizado e mantê-los na matriz. Não esqueça de retornar o array.

Personalizando o prefixo de URL REST

Os endpoints personalizados, apesar de serem personalizados, usam o mesmo prefixo que os endpoints padrão. Eles se parecem com mysite.com/wp-json/custom-endpoint/. Talvez você ache isso feio ou não goste de coisas padrão. Alterá-lo é uma questão de uma linha de código. Para fins de teste coloque o código abaixo no functions.php do tema e depois de salvar abra Dashboard – Settings – Permalinks para liberar as regras de reescrita.

add_filter( 'rest_url_prefix', 'rest_url_prefix' );

function rest_url_prefix( ) {
  return 'api';
}

Com o filtro acima, seus endpoints serão mysite.com/api/custom-endpoint/ e abrir o antigo mysite.com/wp-json/custom-endpoint/ URL produzirá um erro 404.

Certifique-se de incluir um número de versão em seus endpoints personalizados, pois um prefixo não é adicionado automaticamente pelo WP. Um prefixo de número de versão garante que as alterações futuras não interrompam os clientes que usam os endpoints antigos. Basta incluir o prefixo da versão ao chamar o register_rest_route() para obter algo como mysite.com/api/v1/custom-endpoint/ e manter todos os seus endpoints atrás desse “v1” para que você possa ter “v2” etc mais tarde.

Teste suas alterações

Remover ou modificar rotas e endpoints da API REST não fará diferença em 98% dos sites WP. "Por que?" – Porque eles não usam a API REST. Mas se o seu, por favor, certifique-se de testar os aplicativos conectados porque, como em tudo, as mudanças podem quebrar as coisas. E é melhor detectar um bug hoje do que amanhã.