RESTful API 帮助，与 HTTP 和 XML 响应混淆
我正在编写一个 API，并且一直在阅读各种来源的教程等。我对回复有点困惑。我编写了一个类，它将发送回 HTTP 标头响应以及 XML 响应。这是正确的还是我应该使用其中之一而不是两者？另外，如何检查我发送的 HTTP 标头响应是否正确？我正在使用 PHP。
我使用以下工具来检查 HTTP 响应： http://www.seoconsultants.com/tools/check-server-headers-工具/ 这表明响应是 HTTP/1.1 200 OK。但是在我的脚本中我将其设置为： 标头（HTTP/1.1 401 未经授权）； 那么哪个是正确的呢？怎样才能正确检查呢？任何想法出了什么问题吗？
非常感谢您的帮助。
I am writing an API and have been reading tutorials etc from various sources. I am a little confused regarding responses. I have written a class that will send back a HTTP header response as well as an XML response. Is this correct or should I be using one or the other and not both? Also how to do I check the HTTP header response I send is correct? Im using PHP.
I have used the following tool to check the HTTP response:
http://www.seoconsultants.com/tools/check-server-headers-tool/
which says the response is HTTP/1.1 200 OK. However in my script I have set it as:
header(HTTP/1.1 401 Unauthorized);
Therefore which is correct? How can I check properly? Any ideas what is going wrong?
Many thanks in advance for your help.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
Redbot http://redbot.org/ 将对您的 HTTP 响应进行非常彻底的分析，以确保您符合HTTP 规范
强烈建议您阅读一些有关 HTTP 协议的介绍性材料。这将使您的生活变得更加轻松。
Redbot http://redbot.org/ will give a very thorough analysis of your HTTP response to ensure you are compliant with the HTTP spec.
You would be well advised to read some introductory material on the HTTP protocol. It will make your life much easier.
在restful 服务中，您使用http 方法get、put、post 和delete，因此http 标头是“包含”的。这种方法调用的有效负载可以按照您喜欢的方式进行格式化（它必须是现有的 mimetype！），因此 xml 也是可能的！您必须区分响应“元数据”和响应有效负载：“元数据”是 http 标头，有效负载是您的 xml 字符串，因此您必须发送两者！否则，您将发送一个空响应:-)
在您的请求中，您必须定义响应应使用哪种数据表示形式（在您的情况下为 xml）。看看这个图片（左边一个人是安静的）。
但是，正如其他答案所说，为此使用框架是一个好主意。
In a restful service, you use the http methods get, put, post and delete, so the http header is there "included". The payload of such a method call can be formatted the way you like (it must be an existing mimetype!), so xml is possible, too! You have to divide between the response "metadata" and the response payload: the "metadata" is a http header, the payload is your xml string, so you have to send both! Otherwise, you would send an empty response :-)
In your request you have to define which data representation (in your case xml) should be used for the response. Have a look at this image (the left one ist restful).
But nevertheless it is a good idea to use a framework for this, like other answers say.
你是从头开始写这个吗？如果您随后使用通用或流行的框架作为基础并集中精力构建您的API方法并让框架处理交付机制
http://inchoo.net/tools-frameworks/symfony2-rest/，您可以通过谷歌搜索更多示例
Are you writing this from scratch? if you are then use a common or popular framework as basis and concentrate to building your API methods and let the framework handle the delivery mechanism
http://inchoo.net/tools-frameworks/symfony2-rest/ and you can google for more samples
HTTP 标头可以是您喜欢的任何标头 - 让客户端处理它们。客户端可以使用它们来了解操作（请求）是否成功完成、服务是否可用以及其他常见有用的信息。如果标头是由协议预定义并包含有效数据，或者是由您定义的（无需验证），则标头是正确的。
XML、JSON 或任何其他响应是您想要告诉客户端的数据。它可能包含有关错误、执行操作的结果等的详细信息。
HTTP Headers could be any you like - let the client handle them. Client can use them to find out if the operation (request) finished successfully or not, if the service is available and other common useful stuff. Headers are correct if they are either pre-defined by protocol and contain valid data or they are defined by you (no validations needed).
XML, JSON or any other response is the data you want to tell the client. It may contain details on errors, the results of performed actions and so on.
我不建议你弄乱 HTTP 标头响应。始终将其设置为 200 OK，并在 XML 响应中发回所需的信息。
这样，客户端只需担心 XML 响应。如果出现 HTTP 错误，例如 403 Forbidden，则意味着这是系统级别（服务器配置）而不是应用程序层本身。
I don't suggest you mess with the HTTP header response. Keep it always set to 200 OK, and send back the needed information in the XML response.
That way, the client has to worry only about the XML response. In case there was an HTTP error, such as 403 Forbidden, it would mean this is on the system level (sever configuration) rather than on the application layer itself.