A versão do WordPress 4.5 adicionou a pouco tempo a possibilidade de implementação de uma REST API utilizando apenas recursos contidos na instalação. Isso foi magnífico! Agora podemos escrever aplicações que consomem apenas dados, o que é ótimo quando estamos falando de plataformas diferentes não só da web, mas assim como na vida nem tudo são flores, essa novidade traz consigo alguns efeitos colaterais resultantes desta “flexibilidade” que a comunidade está correndo atrás para resolver. Neste artigo iremos abordar um ou mais destes pontos e opinar a respeito.
Em primeiro lugar, a forma como as requisições são compreendidas pelo servidor. Com a nova maneira de receber estes dados a partir do WordPress 4.5, pela interface REST API, abriram-se várias possibilidades de haver problemas relacionados a forma que esses dados são processados, por exemplo, existem requisições GET, POST, PUT, JSON que são misturadas na hora de receber os dados de consulta.
A possibilidade além de ser atraente a primeira vista também é perigosa, uma vez que esses dados vem de uma forma ou de outra, dependendo do tipo de requisição. Em baixo nível o WordPress 4.5 possui funções cujo objetivo é “cortar” esses dados passados para a interface chamando os métodos nativos “wp_unslash()” e “wp_slash()” . Isso significa que os dados passados pelas superglobais $_* podem ser passados diretamente, mas outros tipo de dados necessitam ser “cortados” pelo “wp_slash()”.
Por exemplo, os seguintes dados são os mesmos porém passados para interface de forma diferente;
// JSON body:
{“name”: “Paul”}
// Form-data ($_POST)
name=Paul
// ambos resultam em
$request->get_param(‘name’) === ‘Paul’;
Porém, caso os dados possuírem “\” (slashes, codificação padrão usada pelo HTTP), a chamada se torna inconsistente levando a efeitos colaterais como mostrados abaixo.
// JSON body:
{“name”: “Paul\Doe”}
// resulta em
$request->get_param(‘name’) === ‘Paul\Doe’;
// Form-data ($_POST) (“\” após codificado resulta em %3D)
name=Paul%3DDoe
// resulta em(devida forma que o PHP trata a entrada devido as aspas)
$request->get_param(‘name’) === ‘Paul\\Doe’
Isso quer dizer que a aplicação precisa entender a forma que os dados chegam até ela para manipular com consistência a resposta. Para deixar de forma clara:
Dados enviados pela query string($_GET, $request->get_query_params()) são “cortados”.
Dados enviados pelo corpo da requisição utilizando form-encoded ($_POST, $request->get_body_params()) são “cortados” para requisições do tipo POST e não são “cortados” para requisições do tipo PUT e DELETE .
Dados enviados no corpo da requisição codificados como objeto JavaScript JSON-encoded ($request->get_json_params()), não são “cortados”.
Dados enviados pela URL ($request->get_url_params()), não são “cortados” .
Dados enviados e codificados por padrão ($request->get_default_params()), são “cortados”.
A comunidade WordPress considera dados “cortados” um grande erro e estão trabalhando para garantir que apenas dados não “cortados” sejam aceitos pela interface. Se você estiver usando alguma função (métodos como wp_insert_post, wp_update_post, update_post_meta, update_user_meta, wp_insert_term, wp_insert_user, esperam que o conteúdo seja cortado) que espere um dado que seja “cortado”, você deve antes passar estes dados pelo método “wp_slash()“.
A solução definitiva para o problema do REST API será implementada na versão 4.5 do CMS mais popular do mundo, devido à quantidade de plugins que já utilizam o WordPress REST API, muitas mudanças virão com atualizações mínimas, antes da versão final. Fique ligado e sempre use “wp_slash()“, caso você esteja usando alguma das funções mencionadas no retorno de dados de sua API.
Você também pode gostar de ler o artigo abaixo.
