REST API는 왜 이런 구조로 설계됐을까

웹 개발을 하다 보면 GET, POST, PUT, DELETE 같은 HTTP 메서드와 /users/1 같은 URL 구조를 당연하게 받아들이게 되지만, 이런 규칙이 왜 표준처럼 자리 잡았는지 살펴보면 API 설계를 훨씬 수월하게 이해할 수 있습니다. REST(Representational State Transfer)의 핵심 아이디어는 서버가 다루는 모든 것을 "자원(resource)"으로 보고, 그 자원을 URL이라는 이름으로 식별하는 것입니다. 동사(행동)가 아니라 명사(자원)를 URL에 담는 것이 원칙이기 때문에 /getUser가 아니라 /users/1처럼 쓰고, 그 자원에 대해 무엇을 할지는 HTTP 메서드로 표현합니다. GET은 조회, POST는 생성, PUT/PATCH는 수정, DELETE는 삭제라는 역할 분담이 이 원칙에서 나온 것입니다. 또 하나의 핵심 원칙은 무상태성(stateless)입니다. 서버는 이전 요청을 기억하지 않고, 매 요청에 필요한 정보(인증 토큰 등)를 요청 자체에 모두 포함해야 합니다. 이렇게 하면 서버를 여러 대로 늘려도 어느 서버가 요청을 처리하든 결과가 동일해, 수평 확장이 훨씬 쉬워집니다. 실무에서 세션을 서버 메모리 대신 Redis 같은 외부 저장소에 두는 이유도 이 무상태성 원칙과 맞닿아 있습니다. 이런 원칙들을 이해하고 나면, API를 설계할 때 "이 기능은 어떤 자원에 대한 어떤 행위인가"를 먼저 정의하는 습관이 생기고, 이는 곧 일관성 있고 예측 가능한 API로 이어집니다.