PHP 和自定义 HTTP 标头,不好的做法吗?

2024-04-01

我有一个用于返回 json 数据的 PHP 应用程序的 RESTful API 的自定义实现,并且为了传达操作的状态,即请求中是否存在失败,我设置了一个自定义 HTTP 标头(非常简单)。 tiny) json 对象作为字符串。这很有效,因为我可以发送响应并轻松地在客户端检索它们,而不会弄乱发送的实际数据。

问题是,使用这种方法是否有任何我可能没有意识到的缺点?应用程序设置自定义 http 标头似乎并不常见,所以我想知道这是否是一种不好的做法或某种不好的“品味”。


这是个有趣的问题。它不应该成为问题,但您应该考虑以下几点:

  1. 标头对于您的应用程序来说必须是唯一的。不只是现在,而是永远。您应该确保为它们添加前缀,例如X-MyApplication-Foo: Bar。不这样做可能会在将来引起冲突。

  2. 防火墙是有时(很少)有点过分热衷于过滤未知的 HTTP 标头。这应该不是问题,但需要记住。

  3. 与现代浏览器相比,较旧的浏览器对标头字段大小的限制较小,因此您需要尽可能多地进行测试。

是否有原因无法使用标准 HTTP 错误代码?我知道您可能想要提供堆栈跟踪或其他有用的调试信息,但在发生错误的情况下,您是否只返回包含错误信息的 JSON blob,而不是正常的“结果”JSON 数据?您可以根据 HTTP 错误代码轻松检测到差异,并以不同的方式处理这两种情况。

我对您建议的方法感到担忧的原因是标头用于更改或导致浏览器行为- 它们并不是一种数据存储机制。

伪代码示例:

switch(httpResponseCode)
{
    case 200:
        parseResult(json);
        break;
    case 403:
        parseForbidden(json);
        break;
    case 500:
        parseServerError(json);
        break;
    default:
        // bad response code, handle appropriately
}
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)

PHP 和自定义 HTTP 标头,不好的做法吗? 的相关文章

随机推荐