조용한 개발 노트

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

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 Method는 서버에게 “무엇을 할 것인가”를 전달하는 수단이다.하지만 실무에서는 종종 Method를 단순히 “요청을 보내는 방식” 정도로만 이해한다.이 글에서는 HTTP Method가 단순한 문법이 아니라, 의미와 계약을 담고 있는 규칙이라는 점을 RFC 기준으로 정리한다.1. HTTP Method는 무엇을 표현하는가?HTTP Method는 요청의 의도(Intent)를 표현한다.즉,이 요청은 무엇을 하려는 것인가?서버는 이 요청을 어떻게 해석해야 하는가?를 명확하게 전달하기 위한 장치다.HTTP는 Method에 따라 요청의 의미를 다르게 해석하도록 설계되었다.2. GET과 POST의 근본적인 차이GET과 POST의 차이를 “쿼리스트링 vs Body”로 설명하는 경우가 많다.하지만 이는 표면적인..

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

Spring Web은 단순히 Controller를 만드는 기술이 아니라, HTTP 요청이 애플리케이션 내부를 통과하는 전체 흐름을 정의한 프레임워크다.이 글에서는 지금까지 살펴본 구성 요소들을 하나의 흐름으로 묶고, 실무에서 어떤 선택을 해야 하는지 기준을 정리한다.1. Spring Web 요청 처리 전체 흐름Spring Web MVC 기준으로, HTTP 요청은 다음 순서로 처리된다.브라우저 또는 클라이언트가 HTTP 요청을 전송한다Filter가 요청을 가장 먼저 가로챈다DispatcherServlet이 모든 요청의 진입점이 된다HandlerMapping이 요청을 처리할 Controller를 찾는다HandlerAdapter가 Controller 실행을 준비한다ArgumentResolver가 메서드 파라미..

요청 데이터가 Controller 메서드의 파라미터로 정상적으로 변환되었다면, 다음으로 고려해야 할 것은 입력 값이 올바른지, 그리고 문제가 발생했을 때 이를 어떻게 응답할 것인지다.Spring Web MVC는 이 두 문제를 Validation과 Exception Handling이라는 메커니즘으로 분리해 다룬다.1. Validation의 역할Validation은 요청 데이터가 비즈니스 로직을 수행하기에 적절한 상태인지 검증하는 과정이다.여기서 중요한 점은, Validation이 에러 처리의 시작점이라는 것이다.형식이 잘못된 요청필수 값이 누락된 요청허용 범위를 벗어난 값이런 문제들은 비즈니스 로직이 실행되기 전에 차단되어야 한다.2. Bean Validation 기반 검증Spring Web MVC는 Be..

Spring Web MVC의 Controller 메서드를 보면, 요청 데이터가 별다른 코드 없이도 메서드 파라미터로 자연스럽게 전달되는 것처럼 보인다.@PathVariable, @RequestParam, @RequestBody 같은 어노테이션이 자동으로 동작하는 이유는, Spring Web 내부에서 ArgumentResolver와 HttpMessageConverter가 역할을 나누어 처리하기 때문이다.이 글에서는 요청 데이터가 Controller 메서드의 파라미터로 변환되는 전체 과정을 두 컴포넌트 중심으로 정리한다.1. Controller 메서드 파라미터는 누가 채우는가?HandlerAdapter가 Controller를 실행할 때, 가장 먼저 해결해야 할 문제는 다음이다.이 메서드의 파라미터들은 어디서..

Spring Web MVC에서 모든 HTTP 요청은 DispatcherServlet을 통해 처리된다. Controller가 직접 요청을 받는 것처럼 보이지만, 실제로는 DispatcherServlet이 요청의 시작점이자 중심이다.이 글에서는 DispatcherServlet이 어떤 역할을 하는지, 그리고 HTTP 요청이 들어온 뒤 어떤 순서로 처리되는지를 Spring 공식 문서의 흐름에 따라 정리한다.1. DispatcherServlet의 정체DispatcherServlet은 Spring Web MVC의 핵심 구성 요소로, Front Controller 패턴을 구현한 서블릿이다.Front Controller 패턴이란, 모든 요청을 하나의 진입점에서 받아 공통 처리 로직을 거친 뒤 적절한 핸들러로 위임하는 ..

Spring Web은 Spring Framework에서 HTTP 요청을 애플리케이션 코드로 연결하는 웹 계층을 담당한다.이 글에서는 Spring Web이 무엇을 책임지는지, 그리고 Spring이 웹 요청을 처리하기 위해 어떤 구조와 실행 모델을 선택했는지를 공식 문서의 관점에서 정리한다.1. Spring Web의 역할Spring Web의 가장 핵심적인 역할은 클라이언트로부터 들어오는 HTTP 요청(Request)을 애플리케이션 내부의 코드 흐름으로 전달하고, 그 처리 결과를 다시 HTTP 응답(Response)으로 변환하는 것이다.이를 위해 Spring Web은 다음과 같은 책임을 가진다.URL과 HTTP 메서드를 기준으로 요청을 처리할 핸들러(Controller)를 선택한다요청 파라미터, 경로 변수, ..