홈 › 중급 › 09 / 9

HTTP 와 JSON 기초

요청·응답 구조, 메서드, 상태 코드, HttpClient, JSON 직렬화
섹션 7진행 0 / 9

5. 자주 하는 실수 (Tip)

❌ 실수 1: 상태 코드를 안 보고 본문부터 파싱한다

java
Map<String, Object> m = MiniJson.read(res.body());   // 404 여도 그냥 파싱 시도

에러 응답도 JSON 이라 파싱 자체는 될 수 있지만 필드 구조가 다릅니다. statusCode() 를 먼저 확인합니다.

❌ 실수 2: JSON 을 문자열 이어붙이기로 직접 만든다

java
String bad = "{\"name\":\"" + name + "\"}";   // name 에 " 가 있으면 깨짐

이스케이프를 빠뜨리면 JSON 이 깨집니다. MiniJson.write 나 실무의 Jackson 을 씁니다.

❌ 실수 3: Content-Type 없이 JSON 본문을 보낸다

서버가 본문을 텍스트로만 받아들여 파싱을 안 하거나 415 를 돌려줍니다. POST·PUT 에는 Content-Type: application/json 을 꼭 붙입니다.

❌ 실수 4: 쿼리 값을 인코딩 없이 붙인다

java
String bad = base + "/search?q=" + "김 철수";   // 공백에서 URL 이 끊김

값에 URLEncoder.encode(값, UTF_8) 를 먼저 적용합니다.

❌ 실수 5: 타임아웃을 안 건다

기본 HttpClient 는 무한정 기다릴 수 있습니다. connectTimeout 과 요청별 timeout 을 항상 명시적으로 겁니다.

❌ 실수 6: 연결 거부와 타임아웃을 같은 코드로 처리한다

java
catch (IOException e) { retry(); }   // 상대가 아예 없는데도 계속 재시도

ConnectException 은 상대가 없다는 뜻이라 즉시 재시도해도 대부분 소용없습니다. 원인을 구분해 로그와 재시도 전략을 다르게 가져갑니다.

❌ 실수 7: POST 를 멱등이라 믿고 그냥 재시도한다

타임아웃 뒤 같은 POST 를 다시 보내면 서버에 같은 자원이 두 번 생길 수 있습니다. 재시도 안전성은 다음 레슨(실무 확장 11)의 멱등키에서 다룹니다.

❌ 실수 8: Map.of() 순서가 항상 같다고 믿는다

항목 두 개 이상인 Map.of() 는 실행마다 순회 순서가 바뀝니다. JSON 키 순서에 의존한 문자열 비교 테스트는 가끔씩 실패합니다. 순서가 필요하면 LinkedHashMap 을 씁니다.