HTTP 상태 코드 — 3 자리 숫자로 결과를 읽는다
상태 코드는 백의 자리로 5 가지로 분류한 뒤 아래 2 자리를 읽는다. 성공의 200/201/204, 리다이렉트의 301/302/308, 클라이언트 쪽의 401/403/404, 서버 쪽의 500/502/503 을 구분한다.
「404 와 403 의 차이는?」에 막히지 않기 위해
오류 화면의 스크린숏이 날아와 「이거 고칠 수 있나요」라는 질문을 받는다. 404 인가 403 인가 503 인가에 따라 원인도 고치는 법도 전혀 다른데, 숫자의 생김새만으로는 어느 것이나 똑같아 보인다 — 상태 코드는 암기하려 들면 수십 개나 되어 좌절하는 분야입니다.
암기는 필요 없습니다. 상태 코드는 백의 자리로 5 가지로 분류한 뒤, 자주 만나는 아래 2 자리만 읽는 것이 올바른 사귀는 법입니다. 3 점 세트의 두 번째 「결과는 어땠는가」는, 우선 백의 자리가 답해 줍니다.
조사의 첫수는 이 분류로 정해집니다. 4xx 라면 먼저 리퀘스트 쪽(URL·인증·보낸 내용)을 의심하고, 5xx 라면 서버 쪽(앱의 로그·뒷단의 서비스)을 의심한다. 이 방향을 헷갈리지 않는 것만으로도, 원인 조사의 절반은 끝나 있습니다.
백의 자리로 5 가지로 분류하고, 각 클래스 안에서 「자주 만나는 몇 개」만 구분해 읽는다 — 이것이 상태 코드의 지도입니다. 화살표 끝의 대표 코드가 이 장에서 다루는 전부입니다.
2xx — 성공에도 구분이 있다
성공은 200 만이 아닙니다. 자주 만나는 3 가지를 늘어놓습니다.
API 를 만드는 쪽이 되었을 때, 이 3 가지를 구분해 쓸 수 있는지 아닌지로 답장의 읽기 쉬움이 달라집니다. 「성공했다」만이 아니라 「성공해서, 무엇이 어떻게 되었는가」까지 3 자리로 전하는 것이 2xx 를 다루는 요령입니다.
연습 3-1 — 백의 자리로 분류한다
먼저 백의 자리로 크게 분류하고, 성공 계열의 아래 2 자리를 구분해 읽습니다.
Q1. 상태 코드의 백의 자리를 읽는 법으로 올바른 것은 어느 것입니까.
4xx 는 「당신의 부탁 방식에 문제가 있다」(존재하지 않는 경로, 권한 없음 등), 5xx 는 「부탁은 받았지만, 이쪽의 처리에서 실수했다」는 서버 쪽의 장애입니다. 이 방향을 반대로 외우면 조사의 첫수를 그르칩니다. 백의 자리 → 아래 2 자리 순으로 읽는다 — 이것이 3 자리를 암기하지 않고 끝내는 이 장의 틀입니다.
Q2. POST /orders 로 새 주문의 작성에 성공했을 때, 의미로서 가장 정확한 상태 코드는 어느 것입니까.
201 은 「성공했고, 그 결과로 새 리소스가 만들어졌다」는 것을 명시하는 성공 코드로, 많은 API 는 만들어진 것의 URL 을 Location 헤더에 곁들여 돌려줍니다. 200 이라도 틀렸다고까지는 할 수 없지만 「만들어졌다」는 정보가 빠집니다. 204 는 「성공했지만 돌려줄 본문이 없다」, 301 은 리다이렉트로, 성공 안에서의 구분으로는 201 이 가장 정확합니다.
Q3. DELETE /orders/7 이 성공했고, 서버는 돌려줄 본문을 특별히 가지고 있지 않습니다. 이때 자연스러운 상태 코드는 어느 것입니까.
204 는 「성공했다. 다만 바디는 비어 있다」는 성공 코드로, 삭제나 갱신처럼 돌려줄 것이 없는 조작에 딱 맞습니다. 404 는 「찾을 수 없다」는 실패, 500 은 서버 장애, 100 은 1xx(처리 도중 경과의 연락)로 성공의 보고가 아닙니다. 성공에도 200/201/204 의 구분이 있다는 것이 2xx 를 읽는 요점입니다.
3xx — 「다른 곳으로 가세요」의 구분
3xx 의 리스폰스는 「답은 여기에 없습니다. Location 헤더에 적은 URL 로 가세요」라는 안내장입니다. 브라우저는 이것을 받으면 자동으로 이동처에 다시 리퀘스트합니다. 자주 만나는 것은 다음 3 가지이고, 차이는 2 가지 축으로 읽을 수 있습니다.
2 번째 축인 「메서드 보존」은 역사적 경위의 산물입니다. 301/302 에서는 오래된 구현과의 호환을 위해 POST 가 GET 으로 고쳐 쓰여 이동되는 것이 허용되어 있습니다. HTML 페이지의 이전이라면 실질적인 피해는 거의 없지만, API 의 POST 가 GET 으로 둔갑하면 부탁 자체가 바뀌어 버립니다. 그래서 「메서드를 바꾸지 않는다」는 것을 명시한 307/308 이 나중에 마련되었습니다. 영구인가 일시인가 × 메서드를 보존하는가 — 이 2 축으로 4 가지 코드는 정리할 수 있습니다.
4xx 와 5xx — 누구의 문제인지 짚어 낸다
4xx 안에서는, 비슷해 보이는 3 형제를 구별해 말하는 것이 중요합니다.
5xx 안에서는, 이 3 가지를 구분할 수 있으면 장애 대응의 첫수가 달라집니다.
502 를 읽을 수 있으면 강한 이유는, 현대 Web 서버의 다수가 「중계역(nginx 등) + 뒤의 앱」이라는 2 단 구성이기 때문입니다. 502 는 중계역은 살아 있고, 뒤가 쓰러져 있다는 것까지 가르쳐 주고 있습니다. 숫자 하나로, 조사할 곳이 한 단계 좁혀지는 것입니다.
연습 3-2 — 리다이렉트와 오류를 구분한다
3xx 의 구분과, 4xx·5xx 안에서의 구분입니다. 실무에서 조사의 첫수가 달라집니다.
Q4. 사이트를 http://example.com 에서 https://example.com 으로 영구 이전했습니다. 301 을 고르는 이유로 올바른 것은 어느 것입니까.
301 Moved Permanently 는 「이 주소는 앞으로 계속 저쪽입니다」라는 선언으로, 브라우저는 다음부터 곧장 새 URL 로 갈 수 있도록 이 이동을 캐시할 수 있고, 검색 엔진은 평가를 새 URL 로 이어받습니다. 일시적인 이동은 그것이 캐시·등록되면 곤란하므로 302 Found 를 사용합니다. 영구인가 일시인가 — 이 한 단어의 차이가 SEO 와 캐시의 동작을 가릅니다.
Q5. 308 Permanent Redirect 가 301 과 별도로 마련되어 있는 이유로 올바른 것은 어느 것입니까.
오래된 브라우저 구현에서 비롯된 경위로, 301/302 에서는 POST 가 GET 으로 고쳐 쓰여 이동되는 것이 허용되어 있습니다. POST 인 채로 이동되기를 바라는 API 에서는, 이래서는 바디째 부탁이 바뀌어 버립니다. 308(영구)과 307(일시)은 「메서드를 보존한다」는 것을 명시한 새로운 코드입니다. 속도나 HTTPS 전용 같은 차이가 아닙니다.
Q6. 관리 화면 https://example.com/admin 에 로그인이 끝난 일반 사용자가 접근했더니 거부되었습니다. 「페이지가 존재하지 않는 것이 아니라, 인증은 끝났지만 권한이 부족하다」는 것을 나타내는 가장 정확한 코드는 어느 것입니까.
403 은 「당신이 누구인지는 알았지만, 이것을 할 권한이 없다」입니다. 401 은 이름과 달리 「미인증 — 먼저 인증해 주세요」로, 인증 정보를 붙여 재도전하면 통과할 가능성이 있습니다. 404 는 「그 경로에 리소스를 찾을 수 없다」. 참고로, 관리 화면의 존재 자체를 숨기고 싶은 사이트가 권한 부족에 일부러 404 를 돌려주는 실무도 있어, 코드는 「서버가 그렇게 주장하고 있다」는 것의 표명이라고 짚어 두면 제 7 장의 케이스에서 효과를 봅니다.
이 장에서 가져갈 것
- 상태 코드는 백의 자리로 5 분류 — 도중 경과 / 성공 / 이동 / 클라이언트 쪽의 문제 / 서버 쪽의 장애. 조사의 첫수는 여기서 정해진다
- 성공의 구분: 200 범용 / 201 만들어졌다 / 204 성공했지만 본문 없음
- 리다이렉트는 영구인가 일시인가 × 메서드를 보존하는가의 2 축 — 301·302·308(과 307). 영구는 캐시되고 SEO 평가도 이어진다
- 401 미인증 / 403 권한 부족 / 404 부존재, 500 앱 내부 / 502 뒤가 쓰러져 있다 / 503 일시적으로 무리를 구별해 말한다
결과를 읽는 법이 몸에 익었으니, 다음 장은 3 점 세트의 세 번째 — 왕복 서신에 곁들여지는 「조건과 보충」, 헤더를 읽습니다.