요청과 응답 찾아보기

화면 대신 요청을 증거로 선택합니다

브라우저에 JSON이 보인다고 필요한 보고서 요청을 정확히 관찰한 것은 아닙니다. 페이지 문서, 아이콘, 확장 기능 등 여러 요청이 함께 보일 수 있습니다. 이번 레슨은 Network 목록에서 /report.json 한 요청을 선택하고 URL·메서드·상태·응답 헤더·본문을 연결하는 작업입니다. 화면의 책 제목만 복사하는 대신 어느 요청의 결과인지 남기면 다른 사람이 같은 조건을 재현할 수 있습니다.

로컬 압축 파일의 http_lab.py에는 running_server와 observe가 있습니다. running_server는 공개 보고서를 먼저 계산하고 임시 포트에서 서버를 엽니다. view_http.py는 주소를 출력한 다음 Enter 입력을 기다립니다. 그동안 브라우저에서 관찰하고 터미널로 돌아와 Enter를 누르면 컨텍스트가 서버를 정리합니다. 문서 없는 별도 서버 실행 명령을 추가하지 않고 제공 도구의 수명 안에서만 관찰합니다.

서버는 시작 시 자료를 읽어 스냅샷을 만듭니다. 파일을 수정해도 이미 실행 중인 서버의 응답은 자동으로 바뀌지 않습니다. 이 실습에서 새 자료를 보려면 도구를 정상적으로 정리한 뒤 다시 실행합니다. 출력된 포트도 바뀔 수 있으므로 이전 주소를 그대로 쓰지 않습니다. 자료 준비와 요청 관찰을 구분해서 기록해야 빈 보고서가 파일 오류인지 정말 빈 입력인지 판단할 수 있습니다.

Network에서 대상 행을 찾습니다

브라우저 개발자 도구를 열고 Network 패널을 선택합니다. 관찰 전에 패널을 열어야 이후 요청을 놓치지 않습니다. 도구가 출력한 /report.json 주소로 이동하거나 이미 이동했다면 새로고침합니다. 목록의 이름 또는 URL에서 report.json을 찾고 선택합니다. 도구 이름과 위치는 브라우저 버전마다 조금 다르지만 요청 목록과 Headers, Response에 해당하는 항목을 찾는 목적은 같습니다.

주소창으로 JSON을 직접 열면 이 요청은 fetch 또는 XHR가 아니라 문서 요청으로 표시될 수 있습니다. Fetch/XHR 필터만 켜면 찾고 싶은 행을 숨길 수 있으므로 처음에는 All에 해당하는 전체 요청으로 확인합니다. 목록이 비면 서버가 실행 중인지 확인하기 전에 필터와 기록 버튼 상태도 살펴봅니다. 목록에 없는 요청과 목록에 있지만 실패한 요청은 다른 관찰입니다.

Headers의 일반 정보에서 Request URL, Request Method, Status Code를 읽습니다. Request URL에는 실제 포트와 경로가 있어야 하고 이 서버의 조회 메서드는 GET입니다. 응답 헤더의 Content-Type은 application/json; charset=utf-8입니다. 요청 헤더에 있는 Accept와 응답의 Content-Type은 같은 역할이 아닙니다. 전자는 클라이언트의 수용 형식 선호이고 후자는 서버가 보낸 자료 형식의 설명입니다.

헤더와 본문을 따로 읽습니다

Response에서 rows, completed, total_pages를 확인합니다. rows의 각 항목에는 id, title, pages, completed만 있습니다. JSON 키 completed가 최상위에서는 완료 행 목록이고 행 안에서는 완료 표시라는 점을 구분합니다. 이름이 같아도 위치가 다르면 값의 역할이 다릅니다. Preview는 편하게 펼쳐 볼 수 있는 도구 표현이며 Response의 실제 본문과 함께 읽어 어떤 값이 전달됐는지 확인합니다.

Content-Length는 전송한 본문의 바이트 길이입니다. 한국어 글자 수와 같은 값이라고 생각하면 어긋납니다. UTF-8에서 한글은 여러 바이트를 사용하므로 Python의 문자열 길이와 encode 후 길이를 비교하면 차이를 확인할 수 있습니다. 헤더의 길이가 맞는다는 사실은 공개 열이나 합계의 정확성을 검증한 것은 아닙니다. 전송 형식 검사와 업무 결과 비교를 다른 항목으로 적습니다.

보고서는 이미 SQL에서 공개 열만 선택합니다. 브라우저에서 이름 칸을 숨기는 처리를 하지 않아도 본문에 가상 소유자 값이 없어야 합니다. Response에서 owner_name과 owner_email을 검색하고, 테스트에서는 실제 가상 값도 검사합니다. 화면에 보이지 않는 필드가 응답에 남으면 다운로드와 개발자 도구로 읽을 수 있습니다. 데이터 제공 범위는 서버가 반환하는 내용으로 판단합니다.

관찰표가 재현에 필요한 내용을 담게 합니다

docs/http.md에 실행 시각, 실제 URL, GET, 상태, Content-Type과 응답 일부를 적습니다. 빈 입력이면 rows가 빈 목록이고 total_pages는 0입니다. 자료가 있다면 제목과 합계를 실제 결과대로 바꿉니다. PORT 같은 템플릿 문구를 남긴 채 실제 관찰 완료라고 쓰지 않습니다. 개인정보는 이 실습에 넣지 않으며 본문 전체를 불필요하게 복사하는 대신 공개 구조를 확인할 정도로 기록합니다.

starter의 /report.json은 rows만 반환하도록 되어 있어 일부 테스트가 실패합니다. reporting.py의 build_report가 만든 report를 그대로 응답하는 위치를 찾아 고칩니다. 이전 SQL 결과를 다시 손으로 합산하거나 모든 입력 행을 JSON으로 직렬화하면 보고서 구조 또는 공개 범위가 달라집니다. AssertionError에서 실제 딕셔너리와 기대 딕셔너리를 대조하고 새 HTTP 계층이 기존 계산을 재사용하는지 살펴봅니다.

PermissionError: Operation not permitted가 bind 위치에서 발생하면 해당 환경이 소켓 생성을 제한하는지 확인합니다. 이는 GET 결과의 404가 아닙니다. 이번 작성 환경은 이 제한 때문에 실제 네트워크 검사를 외부 검증으로 남깁니다. 학습자는 로컬 환경에서 README의 검사 명령과 브라우저 관찰을 수행합니다. 자동 검사 통과와 사람이 작성한 관찰표의 정확성은 각각 검토해야 합니다.

서버를 정리한 후에는 새 요청이 더 이상 보고서를 받을 수 없어야 합니다. 브라우저가 이전 내용을 남겨 두면 현재 응답이라고 착각할 수 있으므로 새로고침과 Network의 새 행을 확인합니다. 이전 행의 상태 200은 과거 요청의 기록입니다. 이 레슨의 제출물은 대상 행을 특정할 수 있는 표와 공개 데이터 구조 설명이며, 다음 레슨에서 같은 관찰 도구로 실패 상황의 차이를 비교합니다.