[Code Review - PHP/libcurl] Procuro pessoas para fazer uma review de um cógido que eu fiz para testar a libcurl · JohnVantas

A code review

Há três diretórios de teste aqui, pois, mas requesito que revisem somente dois: pois foram mais os complexos. (Aqueles que tiverem um "R")

sending_requests

Teste inicial: somente mando um GET para uma API que me retorna JSONS e mostro na tela.

requests_test ("R")

Segundo teste: inicio um servidor (server) Flask, populo um ,dict do lado do servidor na rota de POST do server e retorno os dados pela rota GET e populo sua contra-parte no lado do cliente.

downloading_images ("R")

Terceiro teste: mando um pedido GET á um servidor, requisito um README de lá, e termino por salvar a resposta em um arquivo.

O Porque de gastar tempo com libcurl e não uma framework (tipo laravel)

Eu estava estudando sobre laravel na faculdade e acabei, durante as aulas, descobrindo sobre a ferramenta chamada cURL, me interessei, e acabei por substituir o Postman por cURL.
Descobri, pois, que a API do cURL estava desponível em C e descobri também que tinha uma versão para PHP.
Onde eu quero chegar é simples: desejo possuir uma maior compreensão de, e acabar por estudar, como o protocolo HTTP funciona (mandando os pedidos manualmente, com uma linguagem que já mais especializada e voltada á servidores, antes a JS--JS ficaria responsavel somente em enviar as informações para PHP), enquanto acabo por organizar as rotas e a conexão com o banco de dados em uma outra linguagem já com framework.
Eu, resumidamente, quero separar a parte de envio (AJAX) da de validação (PHP) e a execução do backend (qualquer outra linguagem)
~~E... eu gostaria saber se eu estrapolei nestes testes~~

Obrigado pela atenção.

Em sending_requests, não vi motivo para existir a função poolResponseHandler. Afinal, vc cria uma instância de stdClass e fica passando ela para as outras funções, que setam o campo response que só é usado dentro das funções. Como o response (e nenhuma outra informação da classe) é usada fora dela, e ele sempre é sobrescrito toda vez que uma requisição é feita, acaba ficando meio que sem função.

Ou seja, poderia ser feito sem esse objeto:

function send_reqs(CurlHandle $handler): void {
    for ($i = 1; $i <= 10; $i++) {
        curl_setopt($handler, CURLOPT_URL, REQUEST_URL.REQUEST_ROUTE."/$i");
        curl_setopt($handler, CURLOPT_RETURNTRANSFER, true);
        // response só é usado dentro da função, então não precisa do poolResponseHandler
        $response = curl_exec($handler);
        if($response == false) {
            pprint_err_msg("Failed to make request at given url ".REQUEST_URL. "/$i");
        }

        $data = json_decode($response, true);
        pprint_reqs($data);
        sleep(WAIT_TIME);
    }
}

function send_req(CurlHandle $handler): void {
    curl_setopt($handler, CURLOPT_URL, REQUEST_URL.REQUEST_ROUTE."/1");
    curl_setopt($handler, CURLOPT_RETURNTRANSFER, true);
    // response só é usado dentro da função, então não precisa do poolResponseHandler
    $response = curl_exec($handler);
    if($response == false) {
        pprint_err_msg("Failed to make request at given url ".REQUEST_URL);
    }
    printf("%s\n", $response);
}

function main(): int {
    $curl = curl_init();

    send_reqs($curl);
    send_req($curl);

    curl_close($curl);
    return 0;
}

Em download_files até faz sentido porque em uma função vc seta um dos campos do objeto, que depois é usado em outra função. Mas no caso acima, da forma que está, não vejo necessidade do poolResponseHandler.

Se quiser enviar muitas requisições de uma vez, outra opção é usar curl_multi_init e as demais funções curl_multi_*, que roda as requisições em paralelo.