Aucune des réponses (y compris celle acceptée par le PO) ne satisfait réellement aux deux exigences :
- supprimer un avertissement (je prévois de lancer ma propre exception en cas d'échec)
- obtenir les informations d'erreur (au moins, le code de réponse) à partir du flux
Voici mon point de vue :
function fetch(string $method, string $url, string $body, array $headers = []) {
$context = stream_context_create([
"http" => [
// http://docs.php.net/manual/en/context.http.php
"method" => $method,
"header" => implode("\r\n", $headers),
"content" => $body,
"ignore_errors" => true,
],
]);
$response = file_get_contents($url, false, $context);
/**
* @var array $http_response_header materializes out of thin air
*/
$status_line = $http_response_header[0];
preg_match('{HTTP\/\S*\s(\d{3})}', $status_line, $match);
$status = $match[1];
if ($status !== "200") {
throw new RuntimeException("unexpected response status: {$status_line}\n" . $response);
}
return $response;
}
Cela lancera pour un non 200
mais vous pouvez facilement travailler à partir de là, par exemple en ajoutant une simple Response
et return new Response((int) $status, $response);
si cela correspond mieux à votre cas d'utilisation.
Par exemple, pour faire un JSON POST
à un point de terminaison de l'API :
$response = fetch(
"POST",
"http://example.com/",
json_encode([
"foo" => "bar",
]),
[
"Content-Type: application/json",
"X-API-Key: 123456789",
]
);
Notez l'utilisation de "ignore_errors" => true
en el http
context map - ceci empêchera la fonction de lancer des erreurs pour les codes d'état non-2xx.
Il s'agit très probablement de la "bonne" quantité de suppression d'erreurs pour la plupart des cas d'utilisation - je ne recommande pas l'utilisation de l'option @
l'opérateur de suppression d'erreur, car cela supprimera également les erreurs telles que le simple passage de mauvais arguments, ce qui pourrait cacher par inadvertance un bogue dans le code d'appel.