1주차 Quiz & Answer

[LEEJaeHyeok97]

여기에 함께 나눌 퀴즈와 정답을 올려주세요

[nayoung16]

Q. URL은 리소스를 “위치 기반”으로 식별한다고 정의되지만, 실제 환경에서는 CDN, 로드밸런서 등으로 인해 요청이 항상 동일한 물리적 서버로 전달되지 않습니다. 그렇다면 여기서 말하는 “위치”는 어떻게 이해하는 게 좋을까요?

[023-dev]

HTTP가 신뢰성 있는 데이터 전송을 보장한다고 하는데, 실제로는 TCP가 그 역할을 담당합니다. 그렇다면 HTTP와 TCP의 책임 범위를 명확히 구분하고, 만약 UDP 기반으로 HTTP를 구현한다면 어떤 트레이드오프가 생길까요? 실제로 HTTP/3가 QUIC(UDP 기반)을 채택한 이유가 무엇일까요?

[choiwoonsik]

HTTP는 왜 신뢰성 있는 데이터 전송의 책임을 다른 계층으로 위임할까?

[706com]

MIME 타입은 왜 중요하게 작용되며, 없다면 어떤 문제가 생길까?

Details

asdas

[kkatalchae]

백엔드 애플리케이션(WAS) 입장에서는 헤더에 담긴 여러 IP 중 어떤 것을 진짜 사용자의 IP로 신뢰해야 할까요?

[kkatalchae]

• 옵션 A (메서드와 멱등성)
  RESTful API를 설계할 때 POST와 PUT은 모두 데이터를 서버로 전송하는 역할을 하지만, PUT은 멱등성(Idempotency, 여러 번 수행해도 결과가 같음)을 가져야 하고 POST는 그렇지 않습니다. HTTP의 특성을 고려할 때, 왜 이러한 멱등성 구분이 중요하며 실무에서 어떤 예외 상황(예: 네트워크 타임아웃 시 재시도)을 방지할 수 있는지 토론해 봅시다.

• 옵션 B (상태 코드 활용의 깊이)
  일부 실무 환경에서는 API를 설계할 때 HTTP 상태 코드는 무조건 200 OK로 응답하고, 에러 여부는 JSON 본문(Body) 안에 {"code": 500, "message": "error"} 형태로 내려주는 방식을 사용하기도 합니다. 이러한 설계가 RESTful 원칙과 HTTP 웹 아키텍처(캐시, 프록시 장비 등) 관점에서 어떤 문제점(안티 패턴)을 발생시킬 수 있는지 장단점을 비교해 봅시다.

• 옵션 C (URI와 자원의 표현)
  RESTful API에서는 URI를 통해 '행위'가 아닌 '자원(명사)'을 표현하라고 권장합니다. 하지만 실무에서는 "사용자의 비밀번호를 초기화한다"거나 "특정 프로세스를 강제로 실행시킨다"와 같이 자원으로 표현하기 애매한 동사적 행위들이 존재합니다. HTTP와 REST의 원칙을 해치지 않으면서 이러한 특수한 행위들을 어떻게 URI로 우아하게 풀어낼 수 있을지 의견을 나눠 봅시다.