PHP et les en-têtes HTTP personnalisés, une mauvaise pratique ?

Question

J'ai une implémentation personnalisée d'une API RESTful pour une application PHP qui renvoie des données json, et afin de communiquer l'état de l'opération, c'est-à-dire s'il y a eu des échecs dans la requête, je configure un en-tête HTTP personnalisé avec un objet json (très petit) comme chaîne. Cela fonctionne bien puisque je peux envoyer des réponses et les récupérer facilement côté client sans toucher aux données envoyées.

La question est de savoir si cette méthode présente des inconvénients que je n'ai peut-être pas perçus. Il ne semble pas très courant que les applications définissent des en-têtes http personnalisés. Je me demande donc s'il s'agit d'une mauvaise pratique ou d'un mauvais "goût" en quelque sorte.

Answer 1

Il s'agit d'une question intéressante. Il ne devrait pas y avoir de raison pour que ce soit un problème, mais vous devez prendre quelques éléments en compte :

1. Les en-têtes doivent être uniques pour votre application. Pas seulement maintenant, mais pour toujours. Vous devez vous assurer que vous les préfixez, par ex. X-MyApplication-Foo: Bar . Ne pas le faire pourrait entraîner des conflits à l'avenir.

2. Les pare-feu sont parfois (rarement) un peu trop zélé avec le filtrage des en-têtes HTTP inconnus. Cela ne devrait pas poser de problème, mais c'est une chose à garder à l'esprit.

3. Les anciens navigateurs sont moins limités que les navigateurs modernes en ce qui concerne la taille des champs d'en-tête. Vous devez donc effectuer des tests sur le plus grand nombre possible de navigateurs.

Y a-t-il une raison pour laquelle vous ne pouvez pas utiliser les codes d'erreur HTTP standard ? Je comprends que vous puissiez vouloir fournir des traces de pile ou d'autres informations de débogage utiles, mais dans le cas d'une erreur, ne pourriez-vous pas simplement renvoyer un blob JSON contenant les informations d'erreur, plutôt que les données JSON "résultat" normales ? Vous pourriez facilement détecter la différence sur la base du code d'erreur HTTP et traiter les deux cas différemment.

La raison pour laquelle je suis préoccupé par l'approche que vous suggérez est que les en-têtes sont utilisés pour modifier ou faire en sorte que le navigateur comportement - ils ne sont pas destinés à être un mécanisme de stockage de données.

Exemple de pseudo-code :

switch(httpResponseCode)
{
    case 200:
        parseResult(json);
        break;
    case 403:
        parseForbidden(json);
        break;
    case 500:
        parseServerError(json);
        break;
    default:
        // bad response code, handle appropriately
}