PHP和自定义HTTP头，不好的做法？

我为返回json数据的PHP应用程序定制了一个RESTful API实现，为了传递操作的状态，即请求中是否有失败，我将使用一个（非常小的）json对象作为字符串设置一个自定义HTTP头。这很好，因为我可以在客户端发送响应并轻松地检索它们，而不会干扰发送的实际数据

---

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

这是一个有趣的问题。不应该有任何理由认为这是一个问题，但您应该考虑以下几点：

标题必须是应用程序特有的。不是现在，而是永远。您应该确保在它们前面加前缀，例如

X-MyApplication-Foo:Bar

。不这样做可能会在将来引起冲突。

防火墙有时（很少）过于热心地过滤未知的HTTP头。这本不应该是个问题，但需要记住。

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

有没有理由不能使用标准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
}

---

你是说在状态码里？比如“200{error:true}”？或者是一个真正的标题“X-Something:whatever”？HTTP规范已经解决了这个问题。如果出现故障，您应该在正文中返回正确的HTTP状态代码和错误描述，而不是自定义标题。如果没有正确的HTTP代码来处理问题，该怎么办？@Artefact2然后发送一个指示一般错误的有效HTTP代码（例如500）并在返回的JSON数据中嵌入一个特定的错误代码；这不是您所期望的，但是您仍然可以使用它做一些事情（只要您正确地处理它）。与JSON回复相反，标题可以在应用程序的任何位置设置，这使得在通过AJAX进行调用时，在整个应用程序中替换例如抛出异常语句非常理想。否则，如果一个依赖于另一个依赖于另一个类的类失败，则必须来回发送JSON回复数据以获得错误响应，因此选择报头似乎是为了节省时间。但也许我只是在偷懒。不管怎样，我的观点都很好。不知何故，用应用程序名称作为头的前缀已经很自然了。为什么不使用一个全局数组变量来存储这样的头呢？在将结果写回客户端时，可以将数组序列化为JSON。