对于未通过HTML表单发送的请求，HTTP是否将请求的Content-Type限制为application / x-www-form-urlencoded以用于非文件上载，或者是MIME类型“right”/标准/语义有意义以任何其他方式？
例如，PHP会自动将内容解析为$ _POST，这似乎表明服务器需要x-www-form-urlencoded。另一方面，我可以使用Ajax在HTTP请求内容中发送JSON对象，并将Content-Type设置为application / json。至少有一些服务器技术（例如WSGI）不会尝试解析它，而是以原始形式将其提供给脚本。
我应该在RESTful API中的POST和PUT请求中使用哪种MIME类型来确保符合HTTP的所有服务器实现？我忽略了SOAP和JSON-RPC等技术，因为它们通过HTTP隧道传输协议而不是按预期使用HTTP。
答案 0 :(得分：5)
您应指定最能描述HTTP消息实体主体的内容类型。
例如，PHP会自动将内容解析为$ _POST，这似乎表明服务器需要x-www-form-urlencoded。
服务器不是“期待”x-www-form-urlencoded。 PHP - 为了让开发人员的生活变得更简单 - 只有当$_POST并且实体主体实际上是urlencoded密钥时，才会将表单编码的实体主体解析为Content-Type: x-www-form-urlencoded超全局值字符串。对于使用Content-Type: multipart/form-data到达的消息生成$_FILES数组，将遵循类似的过程。虽然很有帮助，但不幸的是这些超级全球被命名，它们模糊了实际HTTP事务中真正发生的事情。
我应该在RESTful API中的POST和PUT请求中使用什么MIME类型 确保符合HTTP的所有服务器实现？
您应该指定最能描述HTTP消息实体主体的内容类型。始终遵守官方HTTP规范 - 如果您这样做，就不会出错。来自RFC 2616 Sec 7.2.1（强调补充）：
包含实体主体的任何HTTP / 1.1消息应该包含一个 Content-Type标头字段，用于定义该主体的媒体类型。 如果和 仅当Content-Type字段未给出媒体类型时， 收件人可以通过检查媒体类型来尝试猜测媒体类型 用于标识的URI的内容和/或名称扩展名 资源。如果媒体类型仍然未知，则收件人应该 将其视为“application / octet-stream”类型。
任何主流服务器技术都将遵守这些规则。周到的Web应用程序不会信任您的Content-Type标头，因为它可能正确也可能不正确。消息的发起者可以自由发送完全虚假的值。通常会检查Content-Type标头作为初步验证度量，但通过解析实际数据进一步验证内容。例如，如果您将JSON数据输出到REST服务，端点可能首先检查以确保您已发送Content-Type: application/json，但实际上解析了消息的实体主体以确保它确实有效JSON。