2018년 3월 4일 일요일

RESTful - Stateless

Stateless.. 서버가 클라이언트의 상태를 저장하지 않는 것.

클라이언트는 매 요청마다 자신을 인증할 수 있는 Token이나 Key 등을 Request에 포함시켜 전송해야 한다. 또는 연속된 작업에서의 상태 정보를 포함시켜야 할 수도 있다.

이렇게 했을 때 가져갈 수 있는 장점은?
Caching, Load balancing, Scale-out.

단점은? 매 요청시마다 상태 정보를 전달해야 하기 때문에 그 만큼의 네트워크 리소스가 소모될 수 있다. (또는 상태 정보 처리에 따른 서버의 부하..)

/

REST architecture(참고 : https://ko.wikipedia.org/wiki/REST)는 stateless 하면서 동시에 어떤 클라이언트 관련정보도 서버에 저장하지 않는 방식을 사용한다. 즉, 상태 정보는 클라이언트가 관리하고 서버는 scale-out 할 수 있게 된다. (클라이언트의 요청을 어느 서버가 처리하던 동일한 결과를 보장할 수 있다.)

만약에, 대규모 환경에서 동일한 웹서버를 다수 배치해 로드밸런싱 하는 경우에 stateful 하다면 각 서버는 클라이언트의 상태(세션)을 공유할 수 있는 Redis와 같은 별도 시스템이 필요하게 된다.

인증을 거치는 서비스가 Stateless 하다면 매번 인증을 위해 ID / Password를 보내야 하나? 그렇게 해도 되지만 대신할 수 있는 몇 가지 기술이 있다.

- HTTP Basic Auth
- HTTP Digest Authentication
- API Key or Access Token
- OAuth

댓글 없음:

댓글 쓰기