MSA를 공부하다보면, 서비스간에 REST Api로 통신한다고 나와있다.
여기서 말하는 REST의 정의는 무엇인지 찾아보고, 구현해보려한다
REST
자원 및 자원에대한 주소를 지정하는 방법에 대한 아키텍쳐이다.
REST 아키텍쳐를 따르는 시스템을 Restful, API 통신을 Rest Api 라고도 한다.
특징 6가지
1) Uniform (유니폼 인터페이스)
2) Stateless (무상태성)
3) Cacheable (캐시 가능)
4) Self-descriptiveness (자체 표현 구조)
5) Client - Server 구조
6) 계층형 구조
1) 유니폼 인터페이스
URI로 지정된 리소스에 대해, 통일된 인터페이스로 수행되는 것을 의미한다.
나같은 경우는 통일된 (Uniform) 인터페이스라는 표현의 이해가 어려웠는데,
클라이언트의 환경 ( 플랫폼 / 프로그래밍 언어 )에 종속되지 않는 느슨한 결합 ( Loosly Coupling ) 아키텍쳐가 더 이해하기 쉬웠다.
2) 무 상태성
서버단에서 상태 정보(컨텍스트)를 저장하지 않음을 의미한다.
세션이나 쿠키같은 정보를 저장하지않고, Request에 대해 들어온 요청대로 수행하기만한다.
요청에 대해 History 고려 및 정보 저장이 필요없으므로, 구현이 간단해진다는 장점이 있다.
3) 캐시 가능
HTTP 메소드를 사용하기에, 기존 캐시 기능을 그대로 사용할 수 있다.
Last-Modified 혹은 E-tag를 사용하여 데이터 갱신유무를 파악하고, 변화가 없으면 클라이언트의 자체 캐시값을 활용한다
※ HTTP Cash 프로세스
- 리퀘스트 헤더에 Last Modified를 포함하거나, E-tag를 사용하여 보낸다 ( E-tag가 우선됨 )
1) Last Modified 값을 If-modified-Since 헤더에 포함시켜, 서버측의 시간과 비교한다.
2) E-tag 값을 If-None-Match 에 포함시켜, 서버측의 값과 비교한다
=> 값이 같다면 304 Not Modified 리턴코드를 응답하고, 클라이언트는 가지고있는 캐시값을 사용한다.
4) 자체 표현 구조
리퀘스트만 보고도 무슨 내용인지 직관적으로 파악이 가능해야한다.
예를들어, GET http://localhost/customer/123 라는 리퀘스트가 있다고 하자.
단번에 회원중에 키값(회원ID)가 123인 사람을 조회하는 GET 메소드 라는것을 알 수 있다.
5) 클라이언트 - 서버구조
API를 통해 요청하고, 인증이나 컨텍스트 정보를 직접 관리하는 Client 와
접근가능하도록 API를 제공하는 Server 역할로 나누어 독립적인 개발이 가능하도록 한다.
6. 계층형 구조
클라이언트 입장에서는 Api를 통해 서버로 요청하지만,
서버 내부적으로 다양한 계층을 지닐수 있다.
스위치 , WEB 서버등을 통해 사용자 인증, SSL, 로드밸런싱 등을 구현할 수 있으며
Apache Reverse Proxy나 HA Proxy 등을 통해 Host 분리없이 구현할 수 있다.
구현 가이드
1. 자원에 대한 행위는 CRUD를 사용한다.
Create - [HTTP Post] 해당 리소스를 생성한다.
Read - [HTTP Get] 해당 리소스를 조회한다.
Update - [HTTP Put] 해당 리소스를 수정한다.
Delete - [HTTP DELETE] 해당 리소스를 삭제한다.
2. URI는 정보를 표현해야한다. ( 명사형 )
1번과도 연관된 내용이다.
동사는 CRUD로 제한하고, 나머지 자원에 대한 정보는 모두 명사로 표시한다.
3. /로 리소스 계층을 식별한다
ex ) GET http://localhost/customer/123
마지막에 /는 혼동을 줄수있기에 넣지 않는다.
4. 모든 경로에는 소문자를 사용한다.
대소문자에 따라 리소스를 다르게 인식하기 때문에, 대문자는 사용하지 않는다.
5. 하이픈 ( - )을 통한 가독성
언더바 ( _ )는 환경에 따라 보기 힘들수도 있기때문에,
URI 내의 가독성을 높이고 싶으면 하이픈을 사용한다.
ex) GET http://localhost/vip-customer/123 ( O )
GET http://localhost/vip_customer/123 ( X )
※ HTTP Response Code
Rest Api를 통해 리퀘스트에 단순 응답만 하는것이 아닌
다양한 Response Code 들을 통해, 처리결과를 좀더 정확하게 회신주어야한다.
대표적인 값은
2xx (성공): 요청을 성공적으로 받았으며 인식했고 수용하였다
- 200 : 클라이언트 요청을 정상적으로 수행함
- 201 : 서버가 요청한 리소스 생성작업을 성공함
3xx (리다이렉션): 요청 완료를 위해 추가 작업 조치가 필요하다
- 301 : 사용자가 요청한 페이지에 대해 URI가 변경되었다.
4xx (클라이언트 오류): 요청의 문법이 잘못되었거나 요청을 처리할 수 없다
- 400 : 사용자가 요청이 어떤것인지 인식하지 못했을 때
- 401 : 사용자의 권한이 부족하거나 인증이 완료되지 않음
- 403 : 금지된 리소스에 사용자가 접근할 때
- 404 : 존재하지 않는 리소스를 요청했을 때
- 405 : 잘못된 메소드로 서버에 요청했을 때
5xx (서버 오류): 서버가 명백히 유효한 요청에 대해 충족을 실패했다
- 500 : 내부 서버오류로 인해 요청 수행 불가
https://ko.wikipedia.org/wiki/HTTP_%EC%83%81%ED%83%9C_%EC%BD%94%EB%93%9C
HTTP 상태 코드 - 위키백과, 우리 모두의 백과사전
아래는 HTTP(하이퍼텍스트 전송 프로토콜) 응답 상태 코드의 목록이다. IANA가 현재 공식 HTTP 상태 코드 레지스트리를 관리하고 있다. 모든 HTTP 응답 코드는 5개의 클래스(분류)로 구분된다. 상태 코
ko.wikipedia.org
[참조]
'IT > 아키텍처' 카테고리의 다른 글
| MSA ( MicroService Architecture ) (0) | 2021.07.13 |
|---|---|
| Monolithic (0) | 2021.07.03 |
