* 현 포스트에서는 REST에 대한 공부 내용만 담겨있습니다. 직접적인 코드 구현은 다음 포스트에 게시할 예정입니다.
올해 1, 2월에 약 5주간의 기간동안 자바와 Spring MVC로 프로젝트를 했었는데 그때의 경험들을 잊기 전에 오늘은 자바와 관련한 공부 내용을 기록해보려고 해요.
프로젝트를 진행하면서 공부할때, RESTful API라는 용어를 많이 봤었어요.
첫 프로젝트에 자격증 공부를 병행할때라 그랬는지 당시에는 공부해도 이해가 잘 가지 않아서 나중에 다시 공부해야지 했던 개념이었어요.
이번에 공부해보니 프로젝트할 때 알고 사용했으면 더 편했을 것 같아서 아쉽더라고요!
REST란?
REST는 REpresentational State Transfer의 약자로, 풀어서 말하면 "웹에 존재하는 모든 자원(이미지, 동영상, 데이터)에 고유한 이름을 부여하고, 이를 주고받는 규칙"을 의미하고 이 규칙을 잘 지켜서 만든 API를 RESTful API라고 한대요.
사실 이렇게말해도 저도 처음엔 확 와닿지 않았는데, 저처럼 처음에 너무 막연하다 싶으신 분들은 "웹 자원의 상태를 주고받는 규칙" 정도로 생각하고 공부해보시면 조금이나마 쉽게 이해할 수 있지 않을까 생각해요.
이전 프로젝트에서 대부분의 구현을 SSR(Server Side Rendering)으로 했었는데 RESTful API 방식인 줄은 모르고 두 번정도 사용했던 경험이 있어요.
(모르고 썼던거라 규칙은 지키지 못했어요. 그런데 사용했다고 말한 것은 "순수한 데이터(JSON)만 보내는 방식"을 사용했기 때문이에요.)
REST의 핵심규칙
-
자원(Resource)은 '명사'로 표현한다.
예를 들자면 저는 프로젝트할 때,@RequestMappingvalue 값을 "/subject_update.do" 이렇게 줬었어요. 하지만 REST 에서는 "/subjects" 이런식으로 사용해야 해요. -
행위는 'HTTP Method'로 표현한다.
GET: 자원 조회 (Read)
POST: 자원 생성 (Create)
PUT/PATCH: 자원 전체/일부 수정 (Update)
DELETE: 자원 삭제 (Delete)
저는 프로젝트를 전통적인 방식인 'GET'과 'POST' 두가지만 사용해서 2번 규칙을 처음 봤을때 헷갈렸었어요. '그렇게 하지 않아도 돌아가는데?' 이런생각을 하면서 말이에요.
그렇게 생각했던건 REST를 프로토콜로 착각했기때문이에요. 그러면 REST는 무엇이냐 하면 정석적인 표현은 '아키텍처 스타일(Architectural Style)'이라고 해요.
쉽게 말하면, '글의 문법' 같은거에요. 띄어쓰기나 맞춤법이 조금 틀려도 의미는 대충 통하지만 글이 길어지고 복잡해지면 작은 문법적 실수가 가독성을 해치고 글을 이해하는 데 불필요한 시간을 사용하게 만들죠?
이런 불필요한 시간을 방지해서 어떤 개발자가 봐도 직관적이고 유지보수하기 쉽게 만든 규칙이 REST에요.
REST를 많이 사용하는 이유
개발자들이 원래 사용하던 방식보다 더 가볍고 직관적인 소통 방식을 원했기때문도 있지만, 현재에는 모바일 앱, 웹 브라우저, 워치 등 다양한 클라이언트가 등장했기 때문이에요.
위에서 제가 RESTful API 방식을 썼다고 한 이유가 순수한 데이터(JSON)만 보내서라고 했었죠? 만약, 제가 프로젝트에서 사용한 서버와 화면이 강하게 결합되어 있는 SSR방식을 사용했다면 유지보수도 어렵고 데이터를 전달할 때 많이 무거웠을거에요. 하지만 데이터를 가진 서버를 하나두고 프론트엔드만 각각 따로 관리한다면 정말 편하겠죠?
REST 핵심 용어(위에서 언급하지 않은)
-
무상태성(Stateless)
서버는 클라이언트가 누구인지, 이전에 무엇을 했는지 기억하지 않는 대신 토큰을 활용하는 경우가 많아요. 그로인해 서버의 확장성이 좋아져요.
"토큰을 사용하지 않고 매번 정보를 보내면 똑같이 무상태성을 유지할 수 있는 것 아닌가?" 라고 생각한다면 두 가지 문제점이 있어요.
1) 보안 : 아이디와 비밀번호는 민감한 정보인데 매번 서버에 전송한다면 위험 노출
빈도가 너무 높아져요.
2) 성능 : 아이디와 비밀번호를 보내면 매번 DB에서 확인해야하기 때문에 서버에 큰
부담이돼요.
-
멱등성(Idempotency)
연산을 여러 번 수행해도 결과가 달라지지 않는 성질이에요.
REST에서 주요 메서드들의 멱등성은 다음과 같아요 :
• 멱등한 메서드 : GET, PUT, DELETE (여러 번 요청해도 처음 요청 응답 후 서버의 상태가
동일하게 유지됩니다.)
• 멱등하지 않은 메서드 : POST (요청할 때마다 새로운 데이터를 생성하므로 결과가
달라집니다.)
• 예외 : PATCH는 '부분 수정'을 담당하므로, 설계에 따라 다릅니다.
(예: +1 연산은 비멱등, 고정된 값으로 변경은 멱등）
위 용어들을 제대로 이해하고 설계 단계부터 적용한다면, 예외 상황을 효과적으로 제어하고 유지보수가 쉬운 API를 구축하는데 도움이 될 것이라 생각해요.
다음 포스트에선 프로젝트에서 사용했던 코드를 REST를 적용해서 비교해보는 방법으로 포스팅할 예정이에요.
다만, 이전 포스트에서 말씀드렸듯 노트북 사양이 낮아서 VS code에서 직접 구현해보는건 가능할지는 모르겠어요. 한번 방법을 찾아볼게요!
