我目前正在实现一个 RESTful API（没什么大不了的，只是为了一个我正在开发的有趣的博客引擎）并且我对 HTTP 状态兼容性有一些疑问。
要创建一个新的博客文章，我必须做一个 POST 请求，如果一切正常，则创建该文章，然后以与请求对应的格式返回。
我在维基百科的这个页面200 OK上阅读了关于状态的信息
在 POST 请求中，响应将包含描述或包含操作结果的实体
好的。但是还有201 Created状态：
请求已完成并导致创建新资源。
所以我的问题是：当 POST 请求成功并创建新的博客文章时，我会发回这两个 http 状态代码还是一次只允许一个？
我没有从RFC获得此信息，以为我没有完全阅读它。
我在想一次只允许一个 HTTP 状态，但是我应该使用哪一个？
编辑（新问题）：如果该操作正在编辑现有博客文章怎么办？我有一个 URI 上的 PUT 请求，这次我必须先发回200 OK然后再发送一个Location:标头？因为这个位置会和 PUT 请求的 URI 完全一样，除了应该是 GET 请求，可以吗？
所有 2xx 状态均成功。但是，在使用 POST 创建资源的情况下，您可能应该返回 201 以及资源的位置。从规范：
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.2
请求已完成并导致创建新资源。新创建的资源可以被响应实体中返回的 URI 引用，资源的最具体的 URI 由 Location 头字段给出。响应应该包含一个实体，其中包含资源特征和位置列表，用户或用户代理可以从中选择最合适的一个。实体格式由 Content-Type 标头字段中给出的媒体类型指定。源服务器必须在返回 201 状态码之前创建资源。如果无法立即执行该操作，则服务器应该使用 202（已接受）响应来响应。
换句话说，您应该返回：
201 Created
Location: http://www.example.com/path/to/resource
然后，浏览器将同时知道这是要引用的资源，并且请求已经成功。您无需担心多状态。
[我意识到这个答案对于最初的提问者来说有点晚了，但将来可能偶然发现这个问题的其他人可能会感兴趣]
除了 AlBlue 所说的：
换句话说，您应该返回：
201 Created Location: http://www.example.com/path/to/resource
您也可以返回新创建的实体，只要您还设置了Content-Location标头：
POST /make-new-resource
然后
HTTP/1.1 201 Created
Location: http://www.example.com/path/to/resource
Content-Location: http://www.example.com/path/to/resource
[representation of new resource]
如果您不包含Content-Location标头，则任何响应正文都将被解释为新创建资源的资源表示的超文本列表（而不是单个代表）。