읽는 장이 아니라 하는 장입니다. 20분이면 됩니다. 설치할 것도, 계정도, 열쇠도 필요 없습니다 — 브라우저 하나면 됩니다.
앞의 세 장(네트워크 · HTTP · API)에서 말로 본 것을 실제로 봅니다. 지금 이 페이지도 요청과 응답으로 만들어졌습니다.
지금 보고 있는 이 페이지에서 그대로 하세요.
| 운영체제 | 단축키 |
|---|---|
| Windows · Linux | F12 또는 Ctrl-Shift-I |
| macOS | ⌘⌥I |
네트워크(Network) 탭을 고르고 페이지를 새로고침하세요. 목록이 쏟아집니다. 이것이 이 화면 하나를 그리려고 오간 요청 전부입니다.
아무것도 안 보이면 새로고침을 안 한 것입니다. 개발자 도구를 먼저 열고 새로고침해야 그 사이의 요청이 잡힙니다.
목록의 맨 위 줄(document 유형)을 클릭하세요. 오른쪽에 상세가 뜹니다. HTTP에서 표로 봤던 네 조각을 찾아보세요.
| 화면에서 찾을 것 | 앞 장의 무엇인가 |
|---|---|
| Request URL | 주소 |
| Request Method | 메서드 — GET 일 것입니다 |
| Status Code | 상태 코드 — 200 |
| Request Headers | 헤더 — 브라우저가 자기소개한 줄들 |
| Response | 서버가 돌려준 내용 |
여기까지 왔으면 "요청과 응답"은 이제 추상적인 말이 아닙니다.
이번엔 사람용 화면이 아니라 프로그램용 창구를 직접 엽니다. 주소창에 그대로 붙여넣으세요.
글자 뭉치가 보입니다. 이것이 JSON이고, 브라우저가 아니라 프로그램이 읽으라고 만든 응답입니다.
없는 주소를 불러보세요.
404 와 함께 "message": "Not Found" 가 옵니다. 404는 주소
문제 였다는 것을 여기서 확인하는 것입니다.
이번엔 열쇠가 필요한 곳을 불러보세요.
401 이 옵니다. 주소는 맞는데 누구인지 밝히지 않았기 때문입니다. 앞의
404와 이번 401이 다른 문제라는 것이 이 실습의 핵심입니다.
여기까지 했으면 이 세 줄을 스스로 답할 수 있습니다.
막혔다면 회사 네트워크가 api.github.com 을 막고 있을 수 있습니다.
1·2단계만으로도 이 장의 목적은 충분히 달성됩니다.
다음은 방금 본 그 글자 뭉치를 읽는 법입니다 → 데이터의 형태 — JSON · CSV · 문서
HyperTeams□ 목록이 몇 줄인가 — 대개 수십 줄입니다□ Status 열에 200이 보이는가□ Type 열에 document · script · fetch 가 섞여 있는가□ Request Method 가 GET 인가□ 헤더 목록에서 User-Agent 를 찾았는가 (브라우저가 자기 정체를 밝히는 줄)□ Response 를 열어 실제 내용이 보이는가https://api.github.com/users/github□ { } 안에 "이름": 값 이 줄줄이 있는가□ login · name · public_repos 같은 항목이 보이는가https://api.github.com/users/이런계정은없을것입니다1234567https://api.github.com/user□ 404 를 받았다 — 주소가 틀린 것□ 401 을 받았다 — 열쇠가 없는 것□ 두 번 다 서버는 정상이었다 (500이 아니었다)□ 이 페이지를 여는 데 요청이 몇 번 오갔는지 봤다□ 요청의 네 조각(메서드 · 주소 · 헤더 · 본문)을 실제 화면에서 찾았다□ 404와 401을 직접 만들어보고 무엇을 고쳐야 하는지 구분했다