요청 하나를 직접 뜯어보기

읽는 장이 아니라 하는 장입니다. 20분이면 됩니다. 설치할 것도, 계정도, 열쇠도 필요 없습니다 — 브라우저 하나면 됩니다.

앞의 세 장(네트워크 · HTTP · API)에서 말로 본 것을 실제로 봅니다. 지금 이 페이지도 요청과 응답으로 만들어졌습니다.

1단계 — 개발자 도구를 엽니다 (5분)

지금 보고 있는 이 페이지에서 그대로 하세요.

운영체제	단축키
Windows · Linux	`F12` 또는 `Ctrl-Shift-I`
macOS	`⌘⌥I`

네트워크(Network) 탭을 고르고 페이지를 새로고침하세요. 목록이 쏟아집니다. 이것이 이 화면 하나를 그리려고 오간 요청 전부입니다.

text

□ 목록이 몇 줄인가 — 대개 수십 줄입니다□ Status 열에 200이 보이는가□ Type 열에 document · script · fetch 가 섞여 있는가

아무것도 안 보이면 새로고침을 안 한 것입니다. 개발자 도구를 먼저 열고 새로고침해야 그 사이의 요청이 잡힙니다.

목록의 맨 위 줄(document 유형)을 클릭하세요. 오른쪽에 상세가 뜹니다. HTTP에서 표로 봤던 네 조각을 찾아보세요.

text

□ Request Method 가 GET 인가□ 헤더 목록에서 User-Agent 를 찾았는가 (브라우저가 자기 정체를 밝히는 줄)□ Response 를 열어 실제 내용이 보이는가

여기까지 왔으면 "요청과 응답"은 이제 추상적인 말이 아닙니다.

이번엔 사람용 화면이 아니라 프로그램용 창구를 직접 엽니다. 주소창에 그대로 붙여넣으세요.

text

https://api.github.com/users/github

글자 뭉치가 보입니다. 이것이 JSON이고, 브라우저가 아니라 프로그램이 읽으라고 만든 응답입니다.

text

□ { } 안에 "이름": 값 이 줄줄이 있는가□ login · name · public_repos 같은 항목이 보이는가

없는 주소를 불러보세요.

text

https://api.github.com/users/이런계정은없을것입니다1234567

404 와 함께 "message": "Not Found" 가 옵니다. 404는 주소 문제 였다는 것을 여기서 확인하는 것입니다.

이번엔 열쇠가 필요한 곳을 불러보세요.

text

https://api.github.com/user

401 이 옵니다. 주소는 맞는데 누구인지 밝히지 않았기 때문입니다. 앞의 404와 이번 401이 다른 문제라는 것이 이 실습의 핵심입니다.

text

□ 404 를 받았다 — 주소가 틀린 것□ 401 을 받았다 — 열쇠가 없는 것□ 두 번 다 서버는 정상이었다 (500이 아니었다)

여기까지 했으면 이 세 줄을 스스로 답할 수 있습니다.

text

□ 이 페이지를 여는 데 요청이 몇 번 오갔는지 봤다□ 요청의 네 조각(메서드 · 주소 · 헤더 · 본문)을 실제 화면에서 찾았다□ 404와 401을 직접 만들어보고 무엇을 고쳐야 하는지 구분했다

막혔다면 회사 네트워크가 api.github.com 을 막고 있을 수 있습니다. 1·2단계만으로도 이 장의 목적은 충분히 달성됩니다.

다음은 방금 본 그 글자 뭉치를 읽는 법입니다 → 데이터의 형태 — JSON · CSV · 문서