2015-11-06 21:39:33 +01:00
|
|
|
---
|
|
|
|
set: 2
|
|
|
|
code: 200
|
|
|
|
title: OK
|
2015-11-07 02:41:41 +01:00
|
|
|
references:
|
|
|
|
"Rails HTTP Status Symbol": ":not_found"
|
2015-11-06 21:39:33 +01:00
|
|
|
---
|
|
|
|
|
2015-11-07 06:31:20 +01:00
|
|
|
The 200 OK status code indicates that the request has succeeded. The payload
|
|
|
|
sent in a 200 response depends on the request method.
|
|
|
|
|
|
|
|
For the methods defined by this specification, the intended meaning of the
|
|
|
|
payload can be summarized as:
|
2015-11-07 02:41:41 +01:00
|
|
|
|
|
|
|
GET a representation of the target resource
|
|
|
|
|
|
|
|
HEAD the same representation as GET, but without the representation data
|
|
|
|
|
|
|
|
POST a representation of the status of, or results obtained from, the action;
|
|
|
|
|
|
|
|
PUT, DELETE a representation of the status of the action;
|
|
|
|
|
|
|
|
OPTIONS a representation of the communications options;
|
|
|
|
|
|
|
|
TRACE a representation of the request message as received by the end server.
|
|
|
|
|
|
|
|
Aside from responses to CONNECT, a 200 response always has a payload, though an
|
|
|
|
origin server MAY generate a payload body of zero length. If no payload is
|
|
|
|
desired, an origin server ought to send [204 (No Content)](/204) instead. For
|
|
|
|
CONNECT, no payload is allowed because the successful result is a tunnel, which
|
|
|
|
begins immediately after the 200 response header section.
|
|
|
|
|
|
|
|
A 200 response is cacheable by default; i.e., unless otherwise indicated by the
|
|
|
|
method definition or explicit cache controls
|
2015-11-07 04:03:35 +01:00
|
|
|
(see [Section 4.2.2 of RFC7234][2]).
|
2015-11-07 02:41:41 +01:00
|
|
|
|
2015-11-07 04:03:35 +01:00
|
|
|
Source: [RFC7231 Section 6.3.1][1]
|
2015-11-07 02:41:41 +01:00
|
|
|
|
2015-11-07 04:03:35 +01:00
|
|
|
[1]: <http://tools.ietf.org/html/rfc7231#section-6.3.1>
|
|
|
|
[2]: <http://tools.ietf.org/html/rfc7234#section-4.2.2>
|