HTTP 정리 및 질문 리스트 (feat.RESTful)

1. HTTP 정리

📌 주요 상태 코드 요약 정리표 

상태 코드	의미	사용예시
200 OK	성공	일반적인 요청 성공
201 Created	리소스 생성됨	POST로 새로운 리소스 생성
204 No Content	성공했지만 응답 본문 없음	DELETE, PATCH 등 후에 본문 불필요할 때
400 Bad Request	클라이언트 요청 오류	잘못된 파라미터, JSON 파싱 실패
401 Unauthorized	인증 실패	로그인/토큰 없음, 만료
403 Forbidden	권한 없음	로그인은 됐지만 권한 없음
404 Not Found	리소스 없음	경로 또는 리소스 존재하지 않음
405 Method Not Allowed	메서드 허용 안됨	GET만 지원하는 API에 POST 요청 등
409 Conflict	리소스 충돌	중복 요청, 버전 충돌 등
429 Too Many Requests	너무 많은 요청	Rate limit 초과
500 Internal Server Error	서버 내부 오류	예외 발생, 로직 에러 등
502 Bad Gateway	게이트웨이 오류	프록시/로드밸런서가 뒤 서버에서 잘못된 응답 받음
503 Service Unavailable	서버 과부하 or 점검 중	일시적 서비스 불가
504 Gateway Timeout	뒤쪽 서버 응답 지연	프록시가 백엔드로부터 응답 못 받음

 

📌 자주 비교되는 상태 코드 차이

항목	의미 / 용도
401 vs 403	401: 인증이 아예 안 됨 (ex. 토큰 없음) 403: 인증은 됐지만 권한 없음
200 vs 204	200: 응답 본문 있음 204: 응답 본문 없음
404 vs 405	404: URL 자체 없음 405: URL은 있지만 HTTP 메서드가 잘못됨
301 vs 302	301: 영구 이동 (브라우저 캐시) 302: 임시 이동
304 vs 200	304: 캐시된 응답 재사용 (본문 없음) 200: 리소스 전송

 

📌 HTTP 메서드 요약 정리

메서드	설명	멱등성	캐싱
GET	데이터 조회	✅ 있음	✅ 가능
POST	데이터 생성	❌ 없음	❌ 없음
PUT	리소스 전체 수정	✅ 있음	❌ 없음
PATCH	리소스 부분 수정	✅ 있음	❌ 없음
DELETE	리소스 삭제	✅ 있음	❌ 없음
HEAD	GET과 동일, 응답 본문 없음	✅ 있음	✅ 가능
OPTIONS	지원하는 메서드 확인 (CORS 등)	✅ 있음	❌ 없음

 

멱등성: 같은 요청을 여러 번 보내도 결과가 같음 → 안정성, 재시도 전략에 중요
캐싱: 브라우저/서버/프록시 등에서 리소스를 재사용 가능

 

 

📌 RESTful API

항목	좋은 설계	나쁜 설계 (RESTful 하지 않음)
URL 설계	리소스 중심 (/users, /posts/1)	동사 중심 (/getUser, /doLogin)
메서드 사용	CRUD에 맞게 사용 (GET, POST, PUT, DELETE)	모든 기능을 POST 하나로 처리
상태 코드	상황에 맞는 HTTP 상태 코드 명확히 사용	무조건 200만 반환, 오류도 OK 처리
Stateless	서버가 상태 저장하지 않음 (토큰 기반 등)	서버가 세션에 상태 저장
버전 관리	/v1/users, 헤더 기반 등 명시적 버전 관리	버전 구분 없음

 

 

📌 조건부 요청 & 캐싱 관련 헤더

헤더	설명
ETag	리소스의 고유 버전 식별자
If-None-Match	클라이언트가 가진 ETag과 비교해서 같으면 304
Last-Modified	리소스 마지막 수정 시각
If-Modified-Since	클라이언트가 가진 마지막 수정 시각과 비교
Cache-Control	캐시 허용 여부, 기간 등 설정
Expires	캐시 만료 시각 명시

 

2. HTTP 관련 질문 

Q1. 401 Unauthorized와 403 Forbidden의 차이는?

• 401: 인증 실패 → 로그인 or 토큰 필요
  (ex. 토큰이 없거나 만료됨)
• 403: 인증은 되었지만 권한 없음
  (ex. 일반 유저가 관리자 API 접근 시)

Q2. 200 OK와 204 No Content의 차이는?

• 200 OK: 요청 성공 + 응답 본문 있음
• 204 No Content: 요청 성공 + 응답 본문 없음
  (ex. DELETE 성공 후 내용 반환 필요 없을 때)

Q3. RESTful하지 않은 API 설계의 예시는?

• 모든 기능을 POST /doSomething 식으로 설계
• URL이 동사 위주 (/createUser, /getData)
• 서버가 클라이언트의 상태를 기억하는 구조 (REST는 Stateless가 원칙)

Q4. 캐시와 304 Not Modified는 어떤 상황에서 쓰이나요?

• 캐싱은 서버 부하 감소, 속도 향상 목적
• 클라이언트가 If-Modified-Since 또는 If-None-Match 헤더 포함 요청 시,
• 서버 리소스가 변경되지 않았다면 304 응답 → 클라이언트는 기존 캐시 사용

Q5. PUT과 PATCH의 차이는?

• PUT: 리소스 전체를 수정 (대체)
• PATCH: 리소스의 일부분만 수정
  → 둘 다 멱등성을 가지지만 의미는 다름

Q6. 405 Method Not Allowed는 언제 발생하나요?

• 클라이언트가 존재하는 URL에 대해 허용되지 않은 HTTP 메서드로 요청할 때 발생
  (ex. GET /users/1만 허용인데 POST로 요청함)

Q7. 멱등성(Idempotent)과 관련된 HTTP 메서드는?

• 멱등성 있음: GET, PUT, DELETE, HEAD, OPTIONS
• 멱등성 없음: POST
  → 같은 요청을 여러 번 보내도 결과가 같아야 멱등

Q8. 429 Too Many Requests는 언제 발생하나요?

• 사용자가 너무 많은 요청을 짧은 시간에 보냈을 때
• 주로 Rate Limit 적용 시 발생
• Retry-After 헤더를 통해 재시도 시점 명시 가능

Q9. 502 Bad Gateway vs 504 Gateway Timeout 차이?

• 502: 프록시 서버가 뒤쪽 서버로부터 잘못된 응답을 받음
• 504: 프록시 서버가 뒤쪽 서버로부터 응답을 못 받고 타임아웃

Q10. OPTIONS 메서드는 언제 사용하나요?

• 클라이언트가 서버에 요청 가능 메서드와 CORS 관련 정보를 미리 요청할 때 사용
• 주로 브라우저가 Preflight Request로 자동 보냄
• 응답엔 Access-Control-Allow-* 헤더 포함