Chapter 3. HTTP Messages
(해석 또는 이해가 잘못된 부분이 있다면 댓글로 편하게 알려주세요.)
❤️ 원문 번역 ❤️
Status Codes
HTTP status codes are classified into five broad categories, as shown earlier in Table 3-2. This section summarizes the HTTP status codes for each of the five classes.
-
HTTP 상태 코드는 앞서 Table 3-2에서 본 것처럼 5가지의 카테고리로 광범위하게 나누어집니다.
-
이번 섹션에서는 다섯 가지 분류 각각의 HTTP 상태 코드를 요약합니다.
The status codes provide an easy way for clients to understand the results of their transactions. In this section, we also list example reason phrases, though there is no real guidance on the exact text for reason phrases. We include the recommended reason phrases from the HTTP/1.1 specification.
-
상태 코드는 클라이언트가 트랜잭션의 결과를 이해하기 쉽게 만듭니다.
-
이번 섹션에서는 사유 구절의 예시 또한 살펴볼 겁니다. 다만 사유 구절에는 실제 가이드라인이 존재하지 않습니다.
-
이 책은 HTTP/1.1의 명세에서 몇 가지 추천되는 사유 구절을 포함합니다.
200-299 : Success Status Codes
When clients make requests, the requests usually are successful. Servers have an array of status codes to indicate success, matched up with different types of requests. Table 3-7 lists the defined success status codes.
-
클라이언트가 전송한 요청은 보통 성공합니다.
-
서버는 서로 다른 요청 유형에 대응하여 성공을 나타내는 상태 코드 배열을 가지고 있습니다.
-
Table 3-7은 정의되어 있는 성공 상태 코드를 나열한 것입니다.
300-399 : Redirection Status Codes
The redirection status codes either tell clients to use alternate locations for the resources they’re interested in or provide an alternate response instead of the content. If a resource has moved, a redirection status code and an optional Location header can be sent to tell the client that the resource has moved and where it can now be found (see Figure 3-14). This allows browsers to go to the new location transparently, without bothering their human users.
-
리디렉션 상태 코드는 클라이언트가 원하는 리소스가 다른 위치를 사용하고 있음을 알려주거나 콘텐츠를 대신하는 다른 응답을 제공합니다.
-
만약 리소스의 위치가 바뀌었다면 리디렉션 상태 코드와 함께 부가적인 Location 헤더가 전송됩니다. 이 헤더는 리소스가 이동했고 지금은 어디서 해당 리소스를 찾을 수 있는지를 클라이언트에게 알려줍니다. (Figure 3-14)
-
이를 통해 브라우저는 유저를 방해하지 않고 새로운 위치를 투명하게 찾아갈 수 있습니다.
Some of the redirection status codes can be used to validate an application’s local copy of a resource with the origin server. For example, an HTTP application can check if the local copy of its resource is still up-to-date or if the resource has been modified on the origin server. Figure 3-15 shows an example of this. The client sends a special If-Modified-Since header saying to get the document only if it has been modified since October 1997. The document has not changed since this date, so the server replies with a 304 status code instead of the contents.
-
일부 리디렉션 상태 코드는 원본(origin) 서버를 활용하여 애플리케이션의 리소스 지역 복사본을 확인하는 데 사용할 수 있습니다.
-
예시로 HTTP 애플리케이션은 리소스의 지역 복사본이 최신 버전을 유지하고 있는지 혹은 리소스가 원본 서버에서 수정되었는지 확인할 수 있습니다.
-
Figure 3-15가 이러한 예시를 보여줍니다.
-
클라이언트는 오직 1997년 10월 이래로 수정된 적이 있는 문서들만 가져오라는 특수한 의미의 If-Modified-Since 헤더를 전송합니다.
-
해당 날짜 이후로 문서는 변경되지 않았으므로 서버는 콘텐츠 대신 304 상태 코드로 응답합니다.
In general, it’s good practice for responses to non-HEAD requests that include a redirection status code to include an entity with a description and links to the redirected URL(s)—see the first response message in Figure 3-14. Table 3-8 lists the defined redirection status codes.
-
일반적으로 리디렉션 상태 코드를 가진 non-HEAD 요청에 대한 응답에는 설명을 담은 엔티티와 재연결할 링크를 포함하는 것이 좋습니다. - Figure 3-14의 첫 응답 메시지를 참고합니다.
-
Table 3-8은 정의되어 있는 리디렉션 상태 코드입니다.
From Table 3-8, you may have noticed a bit of overlap between the 302, 303, and 307 status codes. There is some nuance to how these status codes are used, most of which stems from differences in the ways that HTTP/1.0 and HTTP/1.1 applications treat these status codes.
-
Table 3-8로부터 여러분은 302, 303, 307 상태 코드가 서로 조금씩 겹쳐 있다는 사실을 눈치챘을 겁니다.
-
이러한 상태 코드들은 약간의 뉘앙스 차이가 있습니다. 대부분은 HTTP/1.0과 HTTP/1.1 애플리케이션이 상태 코드를 처리하는 방식의 차이로부터 비롯되었습니다.
When an HTTP/1.0 client makes a POST request and receives a 302 redirect status code in response, it will follow the redirect URL in the Location header with a GET request to that URL (instead of making a POST request, as it did in the original request).
-
HTTP/1.0 클라이언트가 POST 요청을 생성하고 그에 대한 응답으로 302 리디렉트 상태 코드를 받았다고 가정합니다.
-
그럼 클라이언트는 (원래 수행하려던 요청 POST 요청 대신) Location 헤더에 적힌 리디렉션 URL로 GET 요청을 보낼 겁니다.
HTTP/1.0 servers expect HTTP/1.0 clients to do this—when an HTTP/1.0 server sends a 302 status code after receiving a POST request from an HTTP/1.0 client, the server expects that client to follow the redirect with a GET request to the redirected URL.
-
HTTP/1.0 서버는 HTTP/1.0 클라이언트가 이것을 수행할 거라고 봅니다.
-
HTTP/1.0 클라이언트로부터 POST 요청을 받은 HTTP/1.0 서버가 302 상태 코드를 송신할 때, 서버는 클라이언트가 GET 요청과 함께 리디렉션 URL로 재연결할 거라고 예상합니다.
The confusion comes in with HTTP/1.1. The HTTP/1.1 specification uses the 303 status code to get this same behavior (servers send the 303 status code to redirect a client’s POST request to be followed with a GET request).
-
그러나 혼란은 HTTP/1.1에서 발생합니다.
-
HTTP/1.1의 명세에서는 이와 똑같은 행위를 하기 위해 303 상태 코드를 사용합니다. (서버는 클라이언트의 POST 요청을 리디렉트하여 GET 요청을 전송하게 하기 위해 303 상태 코드를 전달합니다)
To get around the confusion, the HTTP/1.1 specification says to use the 307 status code in place of the 302 status code for temporary redirects to HTTP/1.1 clients. Servers can then save the 302 status code for use with HTTP/1.0 clients.
-
이와 같은 혼란을 회피하고자, HTTP/1.1 명세에서는 HTTP/1.1 클라이언트에 대한 일시적 리디렉션을 위해 302 상태 코드 대신 307 상태 코드를 사용할 것을 권장합니다.
-
그럼 서버는 HTTP/1.0 클라이언트와의 사용을 위해 302 상태 코드를 저장할 수 있습니다.
What this all boils down to is that servers need to check a client’s HTTP version to properly select which redirect status code to send in a redirect response.
- 이 모든 것은 서버가 클라이언트의 HTTP 버전을 확인하여 리디렉션 응답으로 전송할 리디렉션 상태 코드를 적절하게 선택해야 한다는 것으로 요약됩니다.
🧡 요약 정리 🧡
200-299 : Success Status Codes
[1] 200 OK
- 요청이 승인되어 본문에 요청받은 리소스가 포함되었음을 나타내는 상태 코드
[2] 201 Created
- 서버 객체를 생성하는 요청에 관한 상태코드 (ex. PUT)
- 응답의 본문에 생성된 리소스를 참조하기 위한 URL을 포함해야 한다
- 서버는 201 Created 응답 전 반드시 객체를 먼저 생성해야 한다
[3] 202 Accepted
- 요청이 승인되었지만 서버가 아직 액션을 수행하지 않았음을 나타내는 상태 코드
(단, 서버가 요청을 완료한다는 것을 보장하지는 않는다) - 서버는 요청의 상태에 관한 내용과 요청 완료 시점에 대한 추정치 등을 본문에 포함해야 한다
[4] 204 No Content
- 응답 메시지에 헤더와 상태 라인은 존재하지만 본문은 존재하지 않음을 나타내는 상태 코드
- 주로 브라우저를 새 문서로 이동하지 않고 업데이트할 때 사용
ㅤ
300-399 : Redirection Status Codes
[1] 301 Moved Permanently
- 클라이언트가 Location 헤더에 적힌 URL로 영구적으로 리디렉션함을 나타내는 상태 코드
- 다음 요청에서도 리디렉션 URL로 이동
[2] 302 Found
- 클라이언트가 Location 헤더에 적힌 URL로 임시로 리디렉션함을 나타내는 상태 코드
- 다음 요청에서는 리디렉션 이전의 URL로 이동
- 클라이언트는 POST 요청 대신 리디렉션 URL로 GET 요청 전송
- HTTP/1.0에서 주로 사용
[3] 303 See Other
- 302와 유사한 내용의 상태 코드
- HTTP/1.1에서 주로 사용
[4] 307 Temporary Redirect
- 302와 유사한 내용의 상태 코드
(단, 클라이언트는 원래의 요청 메소드를 그대로 사용해야 한다) - HTTP/1.1에서 주로 사용되며 HTTP/1.0과의 호환성 유지(302 상태 코드 저장)
💛 감상 💛
-
상태 코드도 자세하게 파고드니 참 어렵다. 특히 300번대 친구들이 정신 나갈 것 같다. 302나 303이나 307이나 내 눈에는 다 거기서 거기 같다. 내가 이 중에 상태 코드 한 가지를 선택해야 하는 순간이 온다면 웬만하면 307을 고를 것 같다. 우선 원본 요청 메소드를 바꾸지 않는 게 유저 입장에서 덜 귀찮을 것이고, 버전 사이의 호환성이 유지되는 편이 더 좋으니까 말이다. 항상 이 사유 구절을 사용해야 하는 건 아니지만 정의된 사유 구절 자체도 꽤 직관적이다. Temporary Redirect라고 하면 임시 리디렉션이라는 사실을 누구나 쉽게 이해할 수 있다. 우리에게 익숙하게 잘 알려진 상태 코드는 302 Found일지도 모른다. 그렇지만 이것저것 생각하면 대체로 307이 훨씬 나아보인다(물론 상황에 따라 302가 나을 수도 있다).
-
처음 API 명세를 만들고 처음 코드를 짰을 때, PUT(REST로 치면 POST) API에 대한 응답 메시지에 상태 코드로 200을 집어넣었었다. 오늘 글을 읽다보니 스터디를 도와주시던 선배가 코드리뷰에서 201 Created라고 지적해주셨던 게 생각이 났다. 그때는 200과 201이 정확히 어떤 차이인지는 모르고, PUT에는 201을 쓰는구나 정도로 이해하고 있었다. 알고 보니 이것은 엔티티 본문에 리소스가 포함되어 있느냐, 리소스를 참조하기 위한 URL이 포함되어 있느냐의 차이였다. 내가 만든 API에 리소스 참조를 위한 URL이 과연 포함되어 있는지는 모르겠지만... 아무튼 굳이 따지자면 201 Created에 가깝다는 거다.
-
다음 포스팅에서는 짧게 400번대와 500번대 친구들을 살펴볼 거다. 내일은 분량이 짧아서 조금 날로 먹을 수 있을 것 같다(?)
