[Spring] RESTFul 기반의 웹 서비스

하이 ~~  ㅎㅎㅎ

 

시간이 지날 수록 점점 코로나가 심각해 진다 ㅜ_ㅜ 다들 건강 잘챙기셨으면 좋겠다.

 

오늘은 RESTful 기반의 웹서비스에 대한 이론적인 포스팅을 좀 해볼거다.

 

 

RESTful 서비스의 시작

 

RESTful 은 하나의 규약이다. 완벽한 표준은 아니지만 거의 사실상 표준이라 봐도 무방할듯 하다.

 

아래의 그림을 보자

RESTFul 웹서비스는 보통 이 그림대로 흘러간다. 

POST 방식으로 예를 들어보겠다. 간단한 회원 가입을 위한 서비스를 날린다고 생각해보자.

v1/user/userid라는 url 에 JSON 데이터에 회원가입을 위한 데이터를 채워서 서버로 보낸다. 그러면 서버는 해당 날라온 JSON 정보를 Entity 형태로 DB에 insert해준다. 그러고 나면 성공했다는 결과를 또 JSON으로 서버는 클라이언트로 응답해준다. GET이나 PUT , DELETE도 마찬가지 일거다 !

 

그리고 이러한 RESTFul 웹서비스에서 request와 response는 HTTP 프로토콜로 처리된다. 

 

 

REST 란?

 

계속 내가 RESTful 이라고 말하는데 ... 이 REST가 뭔지는 알고 가는게 좋겠다.

REST의 첫 언급은 Roy Fielding 박사의 논문에서 나왔다. 기존 웹서비스들이 HTTP를 적극적으로 활용하지 못하는 문제를 해결하기 위해 제안된 것이다. 이 REST 가 아키텍처는 아니다. HTTP를 보다 더 HTTP 답게 사용할 수 있도록 도와주는 방법론 이라고 생각하자.

 

REST는 Representational State Transfer의 약자이다. 직역해보면 데이터의 representation을 전송해준다는 뜻인데.. 계속읽다보면 이게 무슨말인지 알거다 ㅎㅎ

 

 

 

REST 원리 및 원칙(제약조건)

 

REST는 확장성있는 웹서비스를 만들기 위한 소프트웨어 아키텍처 적인 접근 방식이다. REST를 이용해 우리는 철저한 resource 즉 data 중심의 설계를 할 수 있다.

 

REST를 통해 우리는 

CREATE ( POST ) , READ ( GET ), UPDATE ( PUT), DELETE (DELETE) 와 같은 4가지 HTTP 메소드를  용도에 맞게 사용하게 된다. 흔히 이를 CRUD라고 부르는 거 많이들 들어보셨을 거다.

 

이를 위한 몇가지 원리와 원칙이 있다. 자세하게 알아보자.

 

1) Client - Server 를 분리하라.

 

REST에서는 Client 와 Server를 분리해야한다. 즉 Client는 뷰 처리를 하고 Server는 데이터를 처리한다. 조금 더 구체적으로 말하면 서버는 클라이언트에게 딱 데이터만 전달하고 클라이언트는 그 데이터를 화면에서 별도로 렌더링해서 보여준다. 클라이언트는 이제 웹만이 아니다. 이 서버는 상태를 저장하지 않는 Stateless 서버이다.

 

 

이 REST 서버는 리소스를 관리하는 API를 제공하는데 우리는 URL 콜 을 통해 API 를 호출하고 API는 리소스에 접근이 가능하게 한다. 이러한 모든 과정은 HTTP 프로토콜에 의해 이뤄진다. 서버가 단순히 서버의 기능에만 충실해지다보니 클라이언트는 사용자 인증이나 Context 관리 ( 세션, 로그인 정보 처리 등) 를 직접해줘야하긴 하지만 이를 통해 우리는 서버를 단순화 시키고 확장성이 있게 설계를 할 수 있게 된다.

 

2) Stateless

 

일반적인 웹서비스에서는 서버에서 세션을 관리하는데 이 세션은 요청이 들어왔을 때 클라이언트를 추적하기 위해 만들어진 거다. 그렇게 만들어 놓은 세션으로 다음 요청부터는 그걸 바탕으로 응답이 이루어지게 되는데 이러한 서비스를 Stateful 한 서비스 라고한다.

 

이와 반대로 RESTFul 에서는 Stateless 한 서비스를 지향한다. RESTFul 에서는 더 이상 세션을 사용하지 않기때문에 기존의 웹서비스에서 세션을 기반으로한 인증 방식도 변경이 된다. 토큰 기반의 인증 방식이나 3자 인증 방식 등을 써서 세션을 사용하지 않고 인증을 하게된다.

 

3) Cacheable

 

RESTFul 서비스에서는 HTTP 프로토콜의 캐싱 기능을 적용할 수 있다. 전체적인 아키텍쳐의 구간마다 캐시가 있고 이 RESTFul 서비스를 잘 구현하기 위해서는 이 캐시를 본격적으로 잘 활용해야 할 것이다.

 

웹 서비스의 대부분은 GET 방식의 요청이다. 매번 리소스로 접근하는 방식은 굉~~장~~히 비효율적일 것이다. 이 캐싱방식을 이용한다면 전반적인 성능향상을 기대할 수 있다. WAS, Web Server, 브라우저 등 어디에나 캐시가 있으니 잘 활용하길 바란다. 구현은 HTTP 프로토콜 표준인 "Last-Modified" 태그나 E-Tag를 이용해서 구현하면 된다.

 

4) Layered System

 

 

위의 그림처럼 RESTFul 웹서비스가 이루어지기 위해서는 각각의 노드끼리 통신이 되야하는데, 여기서 인접한 노드끼리만 서비스 통신이 되야한다. 인접한 레이어를 제외하고는 다른 레이어들을 바로 접근할 수가 없다. 이 것은 각 서비스 계층은 캡슐화가 되어 있기에 가능하고 이를 통해서 클라이언트로부터 서비스를 보호할 수 가 있게된다.

 

5) Code on demand

 

이건 최근에는 잘 안쓴다. 서버에서 모든걸 실행하기보다는 클라이언트에서도 실행하게 해서 과부하를 줄이자는 의도인데, 자바 Applet 이나 javascript가 대표적인 예이다. 서버가 클라이언트에 실행가능한 코드를 내려줌으로써 클라이언트의 기능을 일시적으로 확장하거나 커스터마이징할 수가 있다. 이러한 방식은 보안적으로 단점이 잇어 잘 안쓴다고한다.

 

요즘에 SPA 가 대세인데... 이게 비슷한 느낌이 아닐까한다. 다만 SPA는 서버에서 클라이언트로 코드를 내려주는게 아니라 데이터를 내리고 클라이언트가 그 데이터를 가공해서 보여주는일을 하는 것이다.

 

6) Uniform interface

 

REST 디자인 constraints에서 가장 기본적인 제약이다. 통일된 인터페이스를 통해서 기술과 플랫폼에 상관없이 API 호출이 가능하게 한다. 여기서 Resource Identifier 라는 말이 나오는데 이는 URI를 요청의 Endpoint로 쓰겠다는 의미이다. 즉, 어떠한 기술이나 플랫폼에서도 URI만 호출하면 된다는 뜻이다.

 

 

아까 REST의 의미가  Representational State Transfer 라고 했다. 여기서 R 이 Resource가 아니라 Representation일까 하는 의문이 해소된다. Representation은 Resource보다 한단계 더 파고들어간 것을 의미한다. Resource가 더 세분화되는 것이다. 이를 통해서 우리는 하나의 URL 을 이용해서 응답을 다 다르게 가져갈 수 잇게 된다. 이것은 Resource를 아낄 수 있게 해주고 확장성있는 설계를 하게 해준다.  결국 서버가 보내주는 것은 resource가 아니라 representation 이다.

 

내가 실제로 개발하고 있는 API를 예를 들어보겠다.

URL 은 같지만 .. 사용한 Http method나 representation 에 따라 서비스가 달라지는 것 볼 수 있다. 무슨말인지 다들 이해되셨을거라 믿는다.

 

또, 만약 내가 외국인 여행객을 대상으로 하는 어플리케이션을 개발한다고 생각해보자. 미국인에게는 영어로 중국인에게는 중국어로 서비스를 제공하는게 맞다. 그런데 모든 나라 사람들에게 각각의 resource를 제공할 것인가? 굉장히 ... 비효율적이다. 이때 클라이언트와 서바간의 Content negotation을 통해 representation을 선택 한다. ( 영어로 제공할건지? 중국어로 제공한건지? 등의 representation ) 일반적으로는 사전협상 (proactive negotiation) 에 의해서 서버가 선택한다. 그리고 해당하는 representation이 없으면 서버는 406 not Acceptable로 응답한다.

 

그리고 REST는 Self-Descriptive message & API 이다. 어렵게 생각할 필요가 없다. 같은 요청이라도 그 요청은 새로운 요청이고, 응답은 해당 요청의 마지막 응답이라는 말이다. 그래서 그 요청은 그 요청 만 봐도 무슨요청인지 알수있도록 구체적이어야한다. 마찬가지도 응답도 굉장히 꼼꼼하게 해줘야한다.

 

마지막으로 HATEOAS(Hypermedia As The Engine Of Application State) 라는 걸 보자. 

RESTFul 서비스는 요청한 서비스에 대해 데이터를 보내주는게 핵심이다. 이 HATEOAS는 데이터만 보내주는게 아니라 데이터에 대한 관련 링크도 같이 보내주는 것을 의미한다. 아직까지 잘 적용된 개념은 아니지만 나중에 이건 대세 기술이 될 것 같기도하다.  요즘에 AI가 대세인데 나중에는 AI 가 링크를 타고들어가서 정말 자동으로 내가 필요로하는 정보를  가공해서 가져올 수도 잇을 것같다. 앞으로가 기대되는 서비스다.

 

오늘은 전반적인 RESTful 기반의 웹 서비스에 대해 알아봤다. 다음 포스팅에는 CRUD 기능을 가진 프로젝트를 한번 개발해 볼거다. 그럼 오늘도 열공하자 !! 다들 내일 월요일인데 잘 쉬고 다음주도 화이팅하자 !!!