개발을 하다 보면 비슷해 보이는 개념들이 자주 튀어나온다.
웹서버, WAS, API 서버, REST, RESTful API.
이걸 분명하게 구분하지 못하면 코드 외적인 부분에서 자꾸 멈춘다.
이번 글은 그 정리다.

웹서버: "정적인 건 내가 한다"

웹서버는 말 그대로 웹 페이지를 띄워주는 서버다.
HTML, CSS, JS, 이미지 같은 정적 파일을 서빙한다.
예시: Apache, Nginx
역할: “브라우저가 요청한 HTML 파일? 여기 있다.”

한 문장으로 요약하자면:
요청 들어오면, 파일 찾아서 넘겨주는 애.
“가볍게 처리할 수 있는 건 가볍게 처리하자.”

WAS: "동적인 건 내 차례야"

WAS는 Web Application Server다.
프로그램을 실행시켜 동적인 데이터를 응답하는 서버다.

예시: Tomcat, JBoss
역할: “로그인 요청? 그럼 DB랑 얘기 좀 해볼게.”

요청이 단순한 파일이 아니라 로직 실행이 필요할 때 등장한다.
웹서버가 요청을 넘겨주면, WAS가 실제 처리를 한다.

“정적은 넘기고, 동적은 계산하라.”

API 서버: "데이터만 주고받자"

API 서버는 프론트엔드와 백엔드가 데이터를 주고받는 중간 다리다.
HTML 같은 UI는 주지 않는다. 대신 JSON 같은 순수 데이터만 주고받는다.
사용 예시: 모바일 앱, SPA 프론트엔드와 연결
구조: 프론트에서 요청 → API 서버 → DB 조회 → 응답(JSON)
실제로는 WAS가 API 서버 역할을 하는 경우가 많다.
즉, 역할이 완전히 독립된 건 아니다. 경계는 흐릿할 수 있다.

“보여주는 건 프론트의 몫, 나는 값만 넘긴다.”

REST API: "규칙을 지키는 대화"

REST는 하나의 설계 철학이다.
자원을 URI로 표현하고, HTTP 메서드로 행위를 나타낸다.

예시:

GET /users/1         사용자 1번 정보 조회  
POST /users          사용자 생성  
PUT /users/1         사용자 1번 수정  
DELETE /users/1      사용자 1번 삭제

REST의 핵심은 일관성과 예측 가능성이다.
"URI만 봐도 무슨 일을 하려는지 알 수 있게 만들자"는 철학.

“혼란 없는 설계가 좋은 설계다.”

RESTful API: "REST 철학을 끝까지 밀어붙인 버전"

REST를 따르긴 따르는데, 애매하게 따르는 경우가 많다.
RESTful API는 REST의 원칙을 철저히 지킨 API를 뜻한다.

지켜야 할 대표 원칙들:
URI에는 명사만 쓴다 (/getUserInfo X, /users O)
소문자만 사용하고, 언더스코어 대신 하이픈 사용
HTTP 메서드는 의미에 맞게 사용 (조회는 GET, 생성은 POST 등)
상태를 서버에 저장하지 않는다 (Stateless)

“제대로 따르지 않을 거면, 애초에 따르지 마라.”
마지막으로, 개념을 구분하면 사고가 정리된다.
사고가 정리되면 설계가 쉬워진다.
설계가 쉬워지면 구현은 덤이다.

“애매함을 없애면, 실수도 줄어든다.”