本内容摘抄自《RESTful WebServices》 中文译本附录B '42种常见的HTTP响应代码'。
原文作者：Leonard Ricbardson & Sam Ruby
翻译：徐涵、李红军、胡伟

1、三至七种最根本的响应代码

  • 200("OK")
    一切正常。实体主体中的文档（若存在的话）是某资源的示意。
  • 400("Bad Request")
    客户端方面的问题。实体主题中的文档（若存在的话）是一个谬误音讯。心愿客户端可能了解此谬误音讯，并改过问题。
  • 500("Internal Server Error")
    服务期方面的问题。实体主体中的文档（如果存在的话）是一个谬误音讯。该谬误音讯通常杯水车薪，因为客户端无奈修复服务器方面的问题。
  • 301("Moved Permanently")
    当客户端触发的动作引起了资源URI的变动时发送此响应代码。另外，当客户端向一个资源的旧URI发送申请时，也发送此响应代码。
  • 404("Not Found") 和410("Gone")
    当客户端所申请的URI不对应于任何资源时，发送此响应代码。404用于服务器端不晓得客户端要申请哪个资源的状况；410用于服务器端晓得客户端所申请的资源已经存在，但当初曾经不存在了的状况。
  • 409("Conflict")
    当客户端试图执行一个”会导致一个或多个资源处于不统一状态“的操作时，发送此响应代码。

SOAP Web服务只应用响应代码200("OK")和500("Internal Server Error")。无论是你发给SOAP服务器的数据有问题，还是服务器在解决数据的过程中呈现问题，或者SOAP服务器呈现外部问题，SOAP服务器均发送500("Internal Server Error")。客户端只有查看SOAP文档主体（body）（其中蕴含谬误的形容）能力获知谬误起因。客户端无奈仅靠读取响应的前三个字节得悉申请胜利与否。

2、状态码系列。

1XX：告诉

1XX系列响应代码仅在与HTTP服务器沟通时应用。

  • 100("Continue")
    重要水平：中等，但（写操作时）很少用。

这是对HTTP LBYL（look-before-you-leap）申请的一个可能的响应。该响应代码表明：客户端应从新发送初始申请，并在申请中附上第一次申请时未提供的（可能很大或者蕴含敏感信息的）示意。客户端这次发送的申请不会被回绝。对LBYL申请的另一个可能的响应是417("Expectation Failed")。

申请报头：要做一个LBYL申请，客户端必须把Expect申请报头设为字符串"100-continue"。除此以外，客户端还须要设置其余一些报头，服务器将依据这些报头决定是响应100还是417。

  • 101("Switching Protocols")
    重要水平：非常低。

当客户端通过在申请里应用Upgrade报头，以告诉服务器它想改用除HTTP协定之外的其余协定时，客户端将取得此响应代码。101响应代码示意“行，我当初改用另一个协定了”。通常HTTP客户端会在收到服务器发来的101响应后敞开与服务器的TCP连贯。101响应代码意味着，该客户端不再是一个HTTP客户端，而将成为另一种客户端。
只管能够通过Upgrade报头从HTTP切换到HTTPS，或者从HTTP1.1切换到某个将来的版本，但理论应用Upgrade报头的状况比拟少。Upgrade报头也可用于HTTP切换到一个齐全不同的协定（如IRC）上，但那须要在Web服务器切换为一个IRC服务器的同时，Web客户端切换为一个IRC的客户端，因为服务器将立即在同一个TCP连贯上开始应用新的协定。

申请报头：客户端把Upgrade报头设置为一组心愿应用的协定。
响应报头：如果服务器批准切换协定，它就返回一个Upgrade报头，阐明它将切换到那个协定，并附上一个空白行。服务器不必敞开TCP链接，而是间接在该TCP连贯上开始应用新的协定。

2XX: 胜利

2XX系列响应代码表明操作胜利了。

  • 200("OK")
    重要水平：十分高。

一般来说，这是客户端心愿看到的响应代码。它示意服务器胜利执行了客户端所申请的动作，并且在2XX系列里没有其余更适宜的响应代码了。

实体主体：对于GET申请，服务器应返回客户端所申请资源的一个示意。对于其余申请，服务器应返回以后所选资源的一个示意，或者刚刚执行的动作的一个形容。

-201("Created")
重要水平：高。

当服务器按照客户端的申请创立了一个新资源时，发送此响应代码。

响应报头：Location报头应蕴含指向新创建资源的标准URI。
实体主体：应该给出新创建资源的形容与链接。若曾经在Location报头里给出了新资源的URI，那么能够用新资源的一个示意作为实体主体。

-202("Accepted")
重要水平：中等。

客户端的申请无奈或将不被实时处理。申请稍后会被解决。申请看上去是非法的，但在理论解决它时有呈现问题的可能。
若一个申请触发了一个异步操作，或者一个须要事实世界参加的动作，或者一个须要很长时间能力实现且没必要让Web客户端始终期待的动作时，这个相应代码是一个适合的抉择。

响应报头：应该把未解决完的申请裸露为一个资源，以便客户端稍后查问其状态。Location报头能够蕴含指向该资源的URI。
实体主体：若无奈让客户端稍后查问申请的状态，那么至多应该提供一个对于何时能解决该申请的预计。

  • 203("Non-Authoritative Information")
    重要水平：非常低。

这个响应代码跟200一样，只不过服务器想让客户端晓得，有些响应报头并非来自该服务器--他们可能是从客户端先前发送的一个申请里复制的，或者从第三方失去的。

响应报头：客户端应明确某些报头可能是不精确的，某些响应报头可能不是服务器本人生成的，所以服务器也不晓得其含意。

  • 204("No Content")
    重要水平：高。

若服务器回绝对PUT、POST或者DELETE申请返回任何状态信息或示意，那么通常采纳此响应代码。服务器也能够对GET申请返回此响应代码，这表明“客户端申请的资源存在，但其示意是空的”。留神与304("Not Modified")的区别。204经常用在Ajax利用里。服务器通过这个响应代码通知客户端：客户端的输出已被承受，但客户端不应该扭转任何UI元素。

实体主体：不容许。

  • 205("Reset Content")
    重要水平：低。

它与204相似，但与204不同的是，它表明客户端应重置数据源的视图或数据结构。如果你在浏览器里提交一个HTML表单，并失去响应代码204，那么表单里的各个字段值不变，能够持续批改它们；但如果失去的响应代码205，那么表单里的各个字段将被重置为它们的初始值。从数据录入方面讲：204适宜对单条记录做一系列编辑，而205适于间断输出一组记录。

  • 206("Partial Content")
    重要水平：对于反对局部GET（partial GET）的服务而言“十分高”，其余状况下“低”。

它跟200相似，但它用于对局部GET申请（即应用Range申请报头的GET申请）的响应。局部GET申请罕用于大型二进制文件的断点续传。

申请报头：客户端为Range申请报头设置一个值。
响应报头：须要提供Date报头。ETag报头与Content-Location报头的值应该跟失常GET申请雷同。

若实体主体是单个字节范畴（byte range），那么HTTP响应里必须蕴含一个Content-Range报头，以阐明本响应返回的是示意的哪个局部，若实体主体是一个多局部实体（multipart entity）（即该实体主体由多个字节范畴形成），那么每一个局部都要有本人的Content-Range报头。
实体主体：不是整个示意，而是一个或者多个字节范畴。

3XX 重定向

3XX系列响应代码表明：客户端须要做些额定工作能力失去所须要的资源。它们通常用于GET申请。他们通常通知客户端须要向另一个URI发送GET申请，能力失去所需的示意。那个URI就蕴含在Location响应报头里。

  • 300("Multiple Choices")
    重要水平：低。

若被申请的资源在服务器端存在多个示意，而服务器不晓得客户端想要的是哪一个示意时，发送这个响应代码。或者当客户端没有应用Accept-*报头来指定一个示意，或者客户端所申请的示意不存在时，也发送这个响应代码。在这种状况下，一种抉择是，服务器返回一个首选示意，并把响应代码设置为200，不过它也能够返回一个蕴含该资源各个示意的URI列表，并把响应代码设为300。

响应报头：如果服务器有首选示意，那么它能够在Location响应报头中给出这个首选示意的URI。跟其余3XX响应代码一样，客户端能够主动追随Location中的URI。
实体主体：一个蕴含该资源各个示意的URI的列表。能够在示意中提供一些信息，以便用户作出抉择。

  • 301("Moved Permanently")
    重要水平：中等。

服务器晓得客户端试图拜访的是哪个资源，但它不喜爱客户端用以后URI来申请该资源。它心愿客户端记住另一个URI，并在今后的申请中应用那个新的URI。你能够通过这个响应代码来避免因为URI变更而导致老URI生效。

响应报头：服务器该当把标准URI放在Location响应报头里。
实体主体：服务器能够发送一个蕴含新URI的信息，不过这不是必须的。

  • 302("Found")
    重要水平：应该理解，特地市编写客户端时。但我不举荐应用它。

这个响应代码市造成大多数重定向方面的凌乱的最根本原因。它应该是像307那样被解决。实际上，在HTTP 1.0中，响应代码302的名称是”Moved Temporarily”，可怜的是，在理论生存中，绝大多数客户端拿它像303一样解决。它的不同之处在于当服务器为客户端的PUT，POST或者DELETE申请返回302响应代码时，客户端要怎么做。
为了打消这一混同，在HTTP 1.1中，该响应代码被重命名为"Found"，并新加了一个响应代码307。这个响应代码目前仍在宽泛应用，但它的含意市混同的，所以我倡议你的服务发送307或者303，而不要发送302.除非你晓得正在与一个不能了解303或307的HTTP 1.0客户端交互。

响应报头：把客户端应从新申请的那个URI放在Location报头里。
实体主体：一个蕴含指向新URI的链接的超文本文档（就像301一样）。

  • 303("See Other")
    重要水平：高。

申请曾经被解决，但服务器不是间接返回一个响应文档，而是返回一个响应文档的URI。该响应文档可能是一个动态的状态信息，也可能是一个更乏味的资源。对于后一种状况，303是一种令服务器能够“发送一个资源的示意，而不强制客户端下载其所有数据”的形式。客户端能够向Location报头里的URI发送GET申请，但它不是必须这么做。
303响应代码是一种规范化资源URI的好方法。一个资源能够有多个URIs，但每个资源的标准URI只有一个，该资源的所有其余URIs都通过303指向该资源的标准URI，例如：303能够把一个对http://www.example.com/softwa...://www.example.com/software/1.0.2.tar.gz。

响应报头：Location报头里蕴含资源的URI。
实体主体：一个蕴含指向新URI的链接的超文本文档。

  • 304("Not Modified")
    重要水平：高。

这个响应代码跟204("No Content")相似：响应实体主体都必须为空。但204用于没有主体数据的状况，而304用于有主体数据，但客户端已领有该数据，没必要反复发送的状况。这个响应代码可用于条件HTTP申请（conditional HTTP request).如果客户端在发送GET申请时附上了一个值为Sunday的If-Modified-Since报头，而客户端所申请的示意在服务器端自星期日（Sunday）以来始终没有扭转过，那么服务器能够返回一个304响应。服务器也能够返回一个200响应，但因为客户端已领有该示意，因而反复发送该示意只会白白浪费宽带。

响应报头：须要提供Date报头。Etag与Content-Location报头的值，应该跟返回200响应时的一样。若Expires, Cache-Control及Vary报头的值自上次发送以来曾经扭转，那么就要提供这些报头。
实体主体：不容许。

  • 305("Use Proxy")
    重要水平：低。

这个响应代码用于通知客户端它须要再发一次申请，但这次要通过一个HTTP代理发送，而不是间接发送给服务器。这个响应代码应用的不多，因为服务器很少在意客户端是否应用某一特定代理。这个代码次要用于基于代理的镜像站点。当初，镜像站点（如http://www.example.com.mysite...）蕴含跟原始站点（如 http://www.example.com/）一样的内容，但具备不同的URI，原始站点能够通过307把客户端从新定向到镜像站点上。如果有基于代理的镜像站点，那么你能够通过把 http://proxy.mysite.com/设为代理，应用跟原始URI（http://www.example.com/）一样的URI来拜访镜像站点。这里，原始站点example.com能够通过305把客户端路由到一个天文上靠近客户端的镜像代理。web浏览器个别不能正确处理这个响应代码，这是导致305响应代码用的不多的另一个起因。

响应报头：Location报头里蕴含代理的URI。

  • 306 未应用
    重要水平：无

306 响应代码没有在HTTP规范中定义过。

  • 307("Temporary Redirect")
    重要水平：高。

申请还没有被解决，因为所申请的资源不在本地：它在另一个URI处。客户端应该向那个URI从新发送申请。就GET申请来说，它只是申请失去一个示意，该响应代码跟303没有区别。当服务器心愿把客户端从新定向到一个镜像站点时，能够用307来响应GET申请。但对于POST，PUT及DELETE申请，它们心愿服务器执行一些操作，307和303有显著区别。对POST，PUT或者DELETE申请响应303表明：操作曾经胜利执行，但响应实体将不随本响应一起返回，若客户端想要获取响应实体主体，它须要向另一个URI发送GET申请。而307表明：服务器尚未执行操作，客户端须要向Location报头里的那个URI从新提交整个申请。

响应报头： 把客户端应从新申请的那个URI放在Location报头里。
实体主体：一个蕴含指向新URI的链接的超文本文档。

4XX：客户端谬误

这些响应代码表明客户端呈现谬误。不是认证信息有问题，就是示意格局或HTTP库自身有问题。客户端须要自行改过。

  • 400("Bad Request")
    重要水平：高。

这是一个通用的客户端谬误状态，当其余4XX响应代码不实用时，就采纳400。此响应代码通常用于“服务器收到客户端通过PUT或者POST申请提交的示意，示意的格局正确，但服务器不懂它什么意思”的状况。

实体主体：能够蕴含一个谬误的形容文档。

  • 401("Unauthorized")
    重要水平：高。

客户端试图对一个受爱护的资源进行操作，却又没有提供正确的认证证书。客户端提供了谬误的证书，或者基本没有提供证书。这里的证书（credential）能够是一个用户名/明码，也能够市一个API key，或者一个认证令牌。客户端经常通过向一个URI发送申请，并查看收到401响应，以获知应该发送哪种证书，以及证书的格局。如果服务器不想让未受权的用户获知某个资源的存在，那么它能够谎报一个404而不是401。这样做的毛病是：客户端须要当时晓得服务器承受哪种认证--这将导致HTTP摘要认证无奈工作。

响应报头：WWW-Authenticate报头形容服务器将承受哪种认证。
实体主体：一个谬误的形容文档。如果最终用户可通过“在网站上注册”的形式失去证书，那么应提供一个指向该注册页面的链接。

  • 402("Payment Required")
    重要水平：无。

除了它的名字外，HTTP规范没有对该响应的其余方面作任何定义。因为目前还没有用于HTTP的微领取零碎，所以它被留作未来应用。尽管如此，若存在一个用于HTTP的微领取零碎，那么这些零碎将首先呈现在web服务畛域。如果想按申请向用户免费，而且你与用户之间的关系容许这么做的话，那么或者用得上这个响应代码。
注：该书印于2008年

  • 403("Forbidden")
    重要水平：中等。

客户端申请的构造正确，然而服务器不想解决它。这跟证书不正确的状况不同--若证书不正确，应该发送响应代码401。该响应代码罕用于一个资源只容许在特定时间段内拜访，
或者容许特定IP地址的用户拜访的状况。403暗示了所申请的资源的确存在。跟401一样，若服务器不想走漏此信息，它能够谎报一个404。既然客户端申请的构造正确，那为什么还要把本响应代码放在4XX系列（客户端谬误），而不是5XX系列（服务端谬误）呢？因为服务器不是依据申请的构造，而是依据申请的其余方面（比如说发出请求的工夫）作出的决定的。

实体主体：一个形容回绝起因的文档（可选）。

  • 404("Not Found")
    重要水平：高。

这兴许是最广为人知的HTTP响应代码了。404表明服务器无奈把客户端申请的URI转换为一个资源。相比之下，410更有用一些。web服务能够通过404响应通知客户端所申请的URI是空的，而后客户端就能够通过向该URI发送PUT申请来创立一个新资源了。然而404也有可能是用来拆穿403或者401.

  • 405("Method Not Allowd")
    重要水平：中等。

客户端试图应用一个本资源不反对的HTTP办法。例如：一个资源只反对GET办法，然而客户端应用PUT办法拜访。

响应报头：Allow报头列出本资源反对哪些HTTP办法，例如：Allow：GET，POST

  • 406("Not Acceptable")
    重要水平：中等。

当客户端对示意有太多要求，以至于服务器无奈提供满足要求的示意，服务器能够发送这个响应代码。例如：客户端通过Accept头指定媒体类型为application/json+hic，然而服务器只反对application/json。服务器的另一个抉择是：疏忽客户端挑剔的要求，返回首选示意，并把响应代码设为200。

实体主体：一个可选示意的链接列表。

  • 407("Proxy Authentication Required")
    重要水平：低。

只有HTTP代理会发送这个响应代码。它跟401相似，惟一区别在于：这里不是无权拜访web服务，而是无权拜访代理。跟401一样，可能是因为客户端没有提供证书，也可能是客户端提供的证书不正确或不充沛。

申请报头：客户端通过应用Proxy-Authorization报头（而不是Authorization）把证书提供给代理。格局跟Authrization一样。
响应报头：代理通过Proxy-Authenticate报头（而不是WWW-Authenticate）通知客户端它承受哪种认证。格局跟WWW-Authenticate一样。

  • 408("Reqeust Timeout")
    重要水平：低。

如果HTTP客户端与服务器建设链接后，却不发送任何申请（或从不发送表明申请完结的空白行），那么服务器最终应该发送一个408响应代码，并敞开此连贯。

  • 409("Conflict")
    重要水平：高。

此响应代码表明：你申请的操作会导致服务器的资源处于一种不可能或不统一的状态。例如你试图批改某个用户的用户名，而批改后的用户名与其余存在的用户名抵触了。

响应报头：若抵触是因为某个其余资源的存在而引起的，那么应该在Location报头里给出那个资源的URI。
实体主体：一个形容抵触的文档，以便客户端能够解决抵触。

  • 410("Gone")
    重要水平：中等。

这个响应代码跟404相似，但它提供的有用信息更多一些。这个响应代码用于服务器晓得被申请的URI过来曾指向一个资源，但该资源当初不存在了的状况。服务器不晓得
该资源的新URI，服务器要是晓得该URI的话，它就发送响应代码301.410和310一样，都有暗示客户端不应该再申请该URI的意思，不同之处在于：410只是指出该资源不存在，但没有给出该资源的新URI。RFC2616倡议“为短期的推广服务，以及属于集体但不持续在服务端运行的资源”采纳410.

  • 411("Length Required")
    重要水平：低到中等。

若HTTP申请蕴含示意，它应该把Content-Length申请报头的值设为该示意的长度（以字节为单位）。对客户端而言，有时这不太不便（例如，当示意是来自其余起源的字节流时）。
所以HTTP并不要求客户端在每个申请中都提供Content-Length报头。但HTTP服务器能够要求客户端必须设置该报头。服务器能够中断任何没有提供Content-Length报头的申请，并要求客户端从新提交蕴含Content-Length报头的申请。这个响应代码就是用于中断未提供Content-Lenght报头的申请的。如果客户端提供谬误的长度，或发送超过长度的示意，服务器能够中断请求并敞开链接，并返回响应代码413。

  • 412("Precondition Failed")
    重要水平：中等。

客户端在申请报头里指定一些前提条件，并要求服务器只有在满足肯定条件的状况下能力解决本申请。若服务器不满足这些条件，就返回此响应代码。If-Unmodified-Since是一个常见的前提条件。客户端能够通过PUT申请来批改一个资源，但它要求，仅在自客户端最初一次获取该资源后该资源未被他人批改过能力执行批改操作。若没有这一前提条件，客户端可能会有意识地笼罩他人做的批改，或者导致409的产生。

申请报头：若客户但设置了If-Match，If-None-Match或If-Unmodified-Since报头，那就有可能失去这个响应代码。If-None-Match略微特地一些。若客户端在发送GET或HEAD申请时指定了If-None-Match，并且服务器不满足该前提条件的话，那么响应代码不是412而是304，这是实现条件HTTP GET的根底。若客户端在发送PUT，POST或DELETE申请时指定了If-None-Match,并且服务器不满足该前提条件的话，那么响应代码是412.另外，若客户端指定了If-Match或If-Unmodified-Since(无论采纳什么HTTP办法)，而服务器不满足该前提条件的话，响应代码也是412。

  • 413("Request Entity Too Large")
    重要水平：低到中等。

这个响应代码跟411相似，服务器能够用它来中断客户端的申请并敞开连贯，而不须要期待申请实现。411用于客户端未指定长度的状况，而413用于客户端发送的示意太大，以至于服务器无奈解决。客户端能够先做一个LBYL（look-before-you-leap）申请，免得申请被413中断。若LBYL申请取得响应代码为100，客户端再提交残缺的示意。

响应报头：如果因为服务器方面长期遇到问题（比方资源有余），而不是因为客户端方面的问题而导致中断请求的话，服务器能够把Retry-After报头的值设为一个日期或一个间隔时间，以秒为单位，以便客户端能够过段时间重试。

  • 414("Request-URI Too Long")
    重要水平：低。

HTTP规范并没有对URI长度作出官网限度，但大部分现有的web服务器都对URI长度有一个下限，而web服务可能也一样。导致URI超长的最常见的起因是：示意数据明明是该放在实体主体里的，但客户端却把它放在了URI里。深度嵌套的数据结构也有可能引起URI过长。

  • 415("Unsupported Media Type")
    重要水平：中等。

当客户端在发送示意时采纳了一种服务器无奈了解的媒体类型，服务器发送此响应代码。比如说，服务器冀望的是XML格局，而客户端发送的的确JSON格局。
如果客户端采纳的媒体类型正确，但格局有问题，这时最好返回更通用的400。

  • 416("Requestd Range Not Satisfiable")
    重要水平：低。

当客户端所申请的字节范畴超出示意的理论大小时，服务器发送此响应代码。例如：你申请一个示意的1-100字节，但该示意总共只用99字节大小。

申请报头：仅当原始申请里蕴含Range报头时，才有可能收到此响应代码。若原始申请提供的是If-Range报头，则不会收到此响应代码。
响应报头：服务器该当通过Content-Range报头通知客户端示意的理论大小。

  • 417("Expectation Failed")
    重要水平：中等。

此响应代码跟100正好相同。当你用LBYL申请来考查服务器是否会承受你的示意时，如果服务器确认会承受你的示意，那么你将取得响应代码100，否则你将取得417。

5XX 服务端谬误

这些响应代码表明服务器端呈现谬误。一般来说，这些代码意味着服务器处于不能执行客户端申请的状态，此时客户端应稍后重试。有时，服务器可能预计客户端应在多久之后重试。并把该信息放在Retry-After响应报头里。

5XX系列响应代码在数量上不如4XX系列多，这不是因为服务器谬误的几率小，而是因为没有必要如此具体--对于服务器方面的问题，客户端是无能为力的。

  • 500("Internal Server Error")
    重要水平：高。

这是一个通用的服务器谬误响应。对于大多数web框架，如果在执行申请解决代码时遇到了异样，它们就发送此响应代码。

  • 501("Not Implemented")
    重要水平：低。

客户端试图应用一个服务器不反对的HTTP个性。
最常见的例子是：客户端试图做一个采纳了拓展HTTP办法的申请，而一般web服务器不反对此申请。它跟响应代码405比拟类似，405表明客户端所用的办法是一个可辨认的办法，但该资源不反对，而501表明服务器基本不能辨认该办法。

  • 502("Bad Gateway")
    重要水平：低。

只有HTTP代理会发送这个响应代码。它表明代理方面呈现问题，或者代理与上行服务器之间呈现问题，而不是上行服务器自身有问题。若代理根本无法拜访上行服务器，响应代码将是504。

  • 503("Service Unavailable")
    重要水平：中等到高。

此响应代码表明HTTP服务器失常，只是上层web服务服务不能失常工作。最可能的起因是资源有余：服务器忽然收到太多申请，以至于无奈全副解决。因为此问题多半由客户端重复发送申请造成，因而HTTP服务器能够抉择拒绝接受客户端申请而不是承受它，并发送503响应代码。

响应报头：服务器能够通过Retry-After报头告知客户端何时能够重试。

  • 504("Gateway Timeout")
    重要水平：低。

跟502相似，只有HTTP代理会发送此响应代码。此响应代码表明代理无奈连贯上行服务器。

  • 505("HTTP Version Not Supported")
    重要水平： 非常低。

当服务器不反对客户端试图应用的HTTP版本时发送此响应代码。

实体主体：一个形容服务器反对哪些协定的文档。