조용한 개발 노트

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

HTTP API를 개발하다 보면, 서버는 정상적으로 응답을 보내는데 브라우저에서만 요청이 실패하는 상황을 자주 마주한다.콘솔에는 보통 다음과 같은 메시지가 나타난다. Blocked by CORS policy 이 문제는 HTTP 서버의 오류도, 네트워크 장애도 아니다.이 글에서는 CORS가 무엇인지, 왜 HTTP 문제가 아닌지, 그리고 왜 브라우저에서만 발생하는지를 웹 표준 관점에서 정리한다.1. Same-Origin Policy란 무엇인가?CORS를 이해하려면 먼저 Same-Origin Policy를 이해해야 한다.Same-Origin Policy는 브라우저가 기본적으로 적용하는 보안 정책이다.여기서 Origin은 다음 세 요소의 조합으로 정의된다.프로토콜 (http / https)호스트 (도메인)포트이..

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