我目前正在开发一个 REST API，它的核心功能之一是使用各种 HTTP 状态代码来返回状态/错误信息，其中一些可能是扩展信息(例如，如果一个item is not found, some other similar items) which will be in the response body.
除非 HTTP 状态代码为 200 OK(即使是 201 Created 成功代码也会导致 Flash 无法认为它是一个错误)。
所以我的问题是，是否有一种标准方法允许此类客户端请求所有状态代码都是 HTTP 200，并以另一种方式指示<em>真实状态代码？
我想到的一个解决方案是，在 HTTP Accept-* header 系列的模式中，使用 X-Accept-Status 扩展 header 来指定可以处理状态代码，例如Flash 会发送...
X-Accept-Status: 200
...然后任何不在此列表中的状态代码将被映射到一个状态代码，并且错误在响应正文中返回，可能带有另一个扩展 header 指示真实状态代码，例如
X-HTTP-Status-Code: 404 Not Found
这一切看起来有点可怕，并且违反了协议(protocol)，但是如果您的客户端不能使用协议(protocol)属性，那么这是不可避免的。我只是在寻找有点像 X-HTTP-Method-Override 的东西(这是为无法发送 PUT 的客户端解决协议(protocol)的“标准”方式/DELETE 请求)但对于无法理解状态代码的客户端。
最佳答案
好吧，实际上是 HTTP 的问题和 REST是，那个REST真是个好主意，HTTP描述了它的一个非常好的实现...但实际上，许多客户端和服务器只实现了 HTTP 的一部分...
我不认为HTTP是必须的......仍然，REST是个好主意REST系统的完整性是一个强大的属性……所以为什么不使用 HTTP作为一个愚蠢的传输层 REST全系统？
这就是你正在做的，尽管在我看来，你对 HTTP 的坚持有点过分了。及其所有理论上的内置功能……您真的需要在状态代码中传输信息吗？
不要太依赖于你的传输协议(protocol)/层......在头脑中有一个清晰的想法，你的服务应该如何工作......将协议(protocol)语义与其实现分开......在客户端和服务器上...... . 抽象你的 REST完整和状态代码(让它们不仅仅是整数......让它成为枚举或对象......异常(exception)，为什么不呢？)......
然后随意插入协议(protocol)/传输层......
- 制定标准
HTTP实现 - 使用您描述的解决方案做一个 hacky 的(对我来说这似乎完全有效......如果人们使用的技术无法使用标准，您为什么要费心寻找最符合标准的解决方案)<
- 做任何你有时间做的事，你的服务器也能做，二进制，
JSON,XML...任何看起来足够的...
不过有两个技术说明:
- Flash 播放器是
HTTP通过浏览器的流量......它根本无法从浏览器获取状态代码......实际上它取决于浏览器......规范说，它不适用于:“Netscape，Mozilla，Safari， Opera 和适用于 Macintosh 的 Internet Explorer。” ... 所以 IE for windows 应该工作？ Chrome ？我不知道......但我认为，这并不重要，因为显然，你不能依赖它......哦，最明显的是:JavaScript 也做它的HTTP当然是在浏览器上……同样的问题…… - 因为这意味着，如果你能成功找到类似
X-HTTP-Method-Override的东西对于协议(protocol)中内置的响应，一个好的浏览器会理解这一点，并相应地重新映射事物，在决定将哪些信息提供给 JavaScript 或第 3 方插件之前......所以你会又一无所有了……我想……
你应该根据客户端简单地选择你的响应方法......如果客户端无法使用HTTP，也许客户端应该发送一些额外的信息。标准...否则抛出它，遵循标准的是什么...我首先使用标准 HTTP 进行实现，但隐藏了 HTTP自己离开，一旦一切正常，写一个使用
问候
回退
关于asp.net-mvc - 向 Flash、JavaScript 等发送自定义 HTTP 错误信息，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1105426/