조용한 개발 노트

REST는 종종URI를 명사로 쓰는 것GET, POST를 구분하는 것JSON을 반환하는 API정도로 이해된다.하지만 이러한 설명만으로는 REST가 무엇인지, 그리고 왜 REST가 등장했는지를 설명하기에 충분하지 않다.이 글에서는 REST를 하나의 API 스타일로 보지 않고, HTTP를 얼마나 충실하게 사용하는 아키텍처 제약 조건으로서 RFC 관점에서 다시 정리한다.1. REST는 무엇을 해결하려 했는가?REST(Representational State Transfer)는 HTTP를 새로 정의하려는 시도가 아니었다.REST의 출발점은 명확하다. 웹이 이미 잘 동작하고 있는데, 왜 API는 웹처럼 확장되지 않는가? REST는확장 가능하고중간 계층에 친화적이며느슨하게 결합된 시스템을 만들기 위한 아키텍처 제약..

HTTP를 쓰다 보면 가장 이해하기 어려운 영역 중 하나가 캐시(Cache)다.Cache-Control, ETag, If-None-Match 같은 개념은 많이 들어봤지만, 정확히 무엇을 보장하는지는 모호한 경우가 많다.이 글에서는 HTTP 캐시가 왜 존재하는지, 그리고 왜 이렇게 복잡한 규칙을 가지게 되었는지를 RFC 기준으로 정리한다.1. HTTP Cache는 왜 필요한가?HTTP는 네트워크 위에서 동작하는 프로토콜이다.즉,느릴 수 있고비쌀 수 있으며항상 안정적이지 않다이 문제를 완화하기 위해 HTTP는 처음부터 캐시를 전제로 설계되었다.캐시의 목적은 단순하다. 같은 요청에 대해 매번 서버까지 가지 않아도 되게 만드는 것 2. HTTP Cache의 기본 모델HTTP 캐시는 다음 위치에 존재할 수 있다...

HTTP 요청과 응답을 보면, Method와 Status Code만큼이나 눈에 띄는 요소가 있다.바로 HTTP Header다.Header는 종종 “부가 정보” 정도로 취급되지만, RFC 관점에서 Header는 요청과 응답의 조건과 맥락을 정의하는 핵심 요소다.이 글에서는 HTTP Header가 어떤 역할을 하는지, 그리고 왜 Header를 제대로 이해하지 않으면 HTTP를 올바르게 사용하고 있다고 보기 어려운지를 RFC 기준으로 정리한다.1. HTTP Header의 역할HTTP 메시지는 크게 세 부분으로 구성된다.Start Line (Request Line / Status Line)HeaderBody이 중 Header는요청이 어떤 조건에서 유효한지응답이 어떤 의미를 가지는지메시지를 어떻게 해석해야 하는지..

HTTP 응답에서 가장 눈에 띄는 정보는 Status Code다.많은 경우 상태 코드는 “대충 성공이면 200, 실패면 400이나 500” 정도로 사용된다.하지만 RFC에서 정의하는 HTTP Status Code는 단순한 숫자가 아니라, 요청과 응답 사이의 명확한 계약이다.이 글에서는 HTTP Status Code가 무엇을 약속하는지, 그리고 왜 정확하게 사용해야 하는지를 RFC 기준으로 정리한다.1. HTTP Status Code의 역할HTTP Status Code는 요청 처리 결과를 서버의 공식 입장으로 표현하는 수단이다.응답 본문보다 먼저 해석되는 정보이기도 하다.클라이언트, 프록시, 캐시는 응답 본문을 보지 않고도 Status Code만으로 다음 동작을 결정할 수 있다.즉, Status Code는..

HTTP는 웹 프레임워크의 기능이 아니다. HTTP는 그보다 훨씬 앞단에 존재하는, 웹이 동작하기 위한 기본 규칙이다.Spring, gRPC, REST API, 브라우저 통신은 모두 이 규칙 위에서 동작한다.이 글에서는 HTTP가 무엇을 책임지는 프로토콜인지, 그리고 HTTP가 무엇을 의도적으로 책임지지 않는지를 공식 RFC 문서를 기준으로 정리한다.1. HTTP는 무엇을 하는 프로토콜인가?HTTP(Hypertext Transfer Protocol)는 리소스를 주고받기 위한 애플리케이션 계층 프로토콜다.RFC 9110은 HTTP를 다음과 같이 정의한다. HTTP는 클라이언트와 서버 간에 요청(Request)과 응답(Response)을 교환하기 위한 표준화된 메시지 규칙이다. 즉, HTTP는요청을 어떻게 ..