1. RESTful API란 무엇인가?
REST란, REpresentational State Transfer 의 약자이다. 여기에 ~ful 이라는 형용사형 어미를 붙여 ~한 API 라는 표현으로 사용된다. 즉, REST 의 기본 원칙을 성실히 지킨 서비스 디자인은 'RESTful'하다라고 표현할 수 있다.
REST는 디자인 패턴이 아닌 아키텍처이다. 좀 더 정확한 표현으로 얘기하자면 REST는 Resource Oriented Architecture(리소스 기반 아키텍처)이다. API 설계의 중심에 자원이 있고 HTTP Method를 통해 자원을 처리하도록 설계하는 것이다.
디자인 패턴 VS 아키텍처?
소프트웨어 아키텍처는 프로그램 내에서 큰 구조로 구성되어 다른 구성 요소들을 관리하는 역할을 한다. 반면에 디자인 패턴은 특정 유형의 문제를 해결하는 방법으로 소프트웨어 아키텍처보다는 조금 더 좁은 개념에 포함된다. 이 둘은 유사성을 가지나 범위의 제한이 존재하는 것이다.
2. REST의 특징
1) Uniform (유니폼 인터페이스)
Uniform interface는 URL로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일을 얘기한다.
2) Stateless (무상태성)
REST는 무상태성의 성격을 갖는다. 다시 말해 작업을 위한 상태정보를 따로 저장하고 관리하진 않는다. 세션 정보나 쿠키 정보를 별도로 저장하고 관리하지 않기 때문에 API서버는 들어오는 요청만을 단순히 처리하면된다. 때문에 서비스의 자유도가 높아지고 서버에 불필요한 정보를 관리하지 않음으로써 구현이 단순해진다.
3) Cacheable (캐시 가능)
REST의 가장 큰 특징 중 하나는 HTTP라는 기존 웹표준을 그대로 사용하기 때문에 웹에서 사용하는 기존 인프라를 그대로 활용이 가능합니다. 따라서 HTTP가 가진 캐싱 기능이 적용 가능합니다. HTTP 프로토콜 표준에서 사용하는 Last-Modified 태그나 E-Tag를 이용하면 캐싱 구현이 가능하니다.
캐시는 성능을 향상 시키기 위한 메모리를 이야기 한다. 예로 들어 컴퓨터에서의 캐싱은 주기억장치와 CPU 사이에 위치하고 자주 사용하는 데이터를 기억한다.
4) Self-descriptiveness(자체 표현 구조)
REST의 또 다른 큰 특징 중 하나는 REST API 메시지만 보고도 이를 쉽게 이해 할 수 있는 자체 표현 구조로 되어 있다는 것이다.
5) Client - Server 구조
REST 서버는 API 제공, 클라이언트는 사용자 인증이나 컨텍스트(세션, 로그인 정보)등을 직접 관리하는 구조로 각각의 역할이 확실히 구분되기 때문에 클라이언트와 서버에서 개발해야 할 내용이 명확해지고 서로간 의존성이 줄어들게 됩니다.
6) 계층형 구조
REST 서버는 다중 계층으로 구성될 수 있으며 보안, 로드 밸런싱, 암호화 계층을 추가해 구조상의 유연성을 둘 수 있고 PROXY, 게이트웨이 같은 네트워크 기반의 중간매체를 사용할 수 있게 합니다.
3-1. REST API의 중심 규칙
1) URL는 정보의 자원을 표현해야 한다.
GET /members/delete/1 (x)
#리소스의 명은 동사보다는 명사를 사용위와 같은 방식은 REST를 제대로 적용하지 않은 URL이다. URL는 자원을 표현하는데 중점을 두어야하고 delete같은 행위에 대한 표현은 들어가서는 안된다
2) 자원에 대한 행위는 HTTP method(GET,POST,PUT,DELETE 등)로 표현
위의 잘못된 URL를 HTTP Method를 통해 수정해 보면
DELETE /members/1 (o)으로 수정할 수 있다. 정보를 가져올때는 GET, 추가의 행위를 표현하고자 할때는 POST를 사용해서 업데이트를 할땐 PUT을 사용한다.
회원정보를 가져오는 URL
GET /member/show/1 (x)
GET /member/1 (0)
# 행위 표현 금지회원을 추가할 때
GET /memberes/insert/2 (x)
POST /members/2 (o)
# GET METHOD는 리소스 생성에 맞지 않다.3-2. RESTful하게 API를 디자인
- 리소스 와 행위 를 명시적이고 직관적으로 분리한다.
- 리소스는 URI로 표현되는데 리소스가 가리키는 것은 명사로 표현되어야 한다.
- 행위는 HTTP Method로 표현하고, GET(조회), POST(생성), PUT(기존 entity 전체 수정), PATCH(기존 entity 일부 수정), DELETE(삭제)을 분명한 목적으로 사용한다.
- Message 는 Header 와 Body 를 명확하게 분리해서 사용한다.
- Entity 에 대한 내용은 body 에 담는다.
- 애플리케이션 서버가 행동할 판단의 근거가 되는 컨트롤 정보인 API 버전 정보, 응답받고자 하는 MIME 타입 등은 header 에 담는다.
- header 와 body 는 http header 와 http body 로 나눌 수도 있고, http body 에 들어가는 json 구조로 분리할 수도 있다.
- API 버전을 관리한다.
- 환경은 항상 변하기 때문에 API 의 signature 가 변경될 수도 있음에 유의하자.
- 특정 API 를 변경할 때는 반드시 하위호환성을 보장해야 한다.
- 서버와 클라이언트가 같은 방식을 사용해서 요청하도록 한다.
- 브라우저는 form-data 형식의 submit 으로 보내고 서버에서는 json 형태로 보내는 식의 분리보다는 json 으로 보내든, 둘 다 form-data 형식으로 보내든 하나로 통일한다.
- 다른 말로 표현하자면 URI 가 플랫폼 중립적이어야 한다.
4. 장단점
- 장점
- 멀티플랫폼 지원 및 연동이 용이하다.
- 원하는 타입으로 데이터를 주고 받을 수 있다.
- 기존 웹 인프라(HTTP)를 그대로 사용 할 수 있다.
- OPEN API를 제공하기 쉽다.
- 단점
*- 사용 할 수 있는 메소드가 4가지뿐이다.(patch라는 메소드도 있다)
- 분산환경에 부적합하다.
- HTTP 통신 모델에 대해서만 지원한다.
