RESTful API 쉽게 이해하기

REST API란

---

REST는 REpresentational State Transfer의 줄임말이다. “State”는 웹 애플리케이션 의 상태를 의미하며, “Transfer”는 이 상태의 전송을 의미한다. 

 

웹서비스에서 전달하려는 자원의 상태 표현 방식이라고 이해하면 쉽다.

 

REST API는 2000년도에 로이 필딩 (Roy Fielding)의 박사학위 논문에서 최초로 소개되었다. 로이 필딩은 HTTP의 주요 저자 중 한 사람으로 그 당시 웹(HTTP) 설계의 우수성에 비해 제대로 사용되어지지 못하는 모습에 안타까워하며 웹의 장점을 최대한 활용할 수 있는 아키텍처로써 REST를 발표했다고 한다.

 

- REST의 규칙을 지키면서 만든 API를 REST API 혹은 RESTful API라고 부른다.

 

 

 

REST API 사용 가이드

---

첫 번째, URI는 정보의 자원을 표현해야 한다. (리소스명은 동사보다는 명사를 사용)
두 번째, 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE)로 표현한다.

 

[참고] HTTP METHOD의 알맞은 역할
- POST, GET, PUT, DELETE 이 4가지의 Method를 가지고 CRUD를 할 수 있다.

POST	POST를 통해 해당 URI를 요청하면 리소스를 생성합니다.
GET	GET를 통해 해당 리소스를 조회합니다. 리소스를 조회하고 해당 도큐먼트에 대한 자세한 정보를 가져온다.
PUT	PUT를 통해 해당 리소스를 수정합니다.
DELETE	DELETE를 통해 리소스를 삭제합니다.

 

 

구성요소

---

1. 자원(Resource)
- 자원은 서버에 존재하는 데이터의 총칭입니다. 모든 자원은 고유의 URI(URL)을 가지며 클라이언트는 이 URI를 지정하여 해당 자원에 대해 CRUD 명령을 수행할 수 있습니다. (ex: /resource/1)

2. 행위(Verb) 
- 행위는 클라이언트가 HTTP Method를 이용하여 자원을 조작하는 것을 의미합니다.

3. 표현(Representation)
- 클라이언트가 HTTP Method로 자원을 조작하면 서버가 그에 대한 응답(JSON, XML)을 보내는데 그것을 의미합니다.

 

 

REST 의 특징

---

1. 서버-클라이언트 구조(Server-Client Architecture)
- 서버는 API 제공, 클라이언트는 유저에 대한 처리를 전담하는 구조를 가지기 때문에 서버와 클라이언트의 역할을 분명하게 구분할 수 있다.

2. 무상태성(Stateless)
- HTTP를 이용하는 만큼 Stateless의 특성을 가진다. 각각의 요청에 대한 정보를 저장하지 않고 별개의 요청으로 처리한다. 덕분에 구현이 쉽고 서버의 부담을 덜어줄 수 있다.

3. 캐시 가능(Cacheable)
- HTTP를 사용하기 때문에 웹의 기본 인프라를 사용할 수 있다. 따라서 캐시 기능을 이용해 같은 URI에 대한 반복된 요청을 효율적으로 처리할 수 있다.​

4. 일관된 인터페이스(Uniform Interface)
- HTTP를 사용할 수 있는 환경이라면 플랫폼에 상관없이 사용할 수 있으며 리소스의 타입에 상관 없이 같은 형태의 요청으로 처리된다.

5. 자체적인 표현 구조(Self-Descriptiveness)
- JSON, XML 등을 이용하는 메세지 구조로 해당 메세지가 무엇을, 어떤 행위를 의미하는지 직관적으로 이해할 수 있다.

6. 계층 구조(Layered System)
- 클라이언트는 대상 서버와 직접 통신하는지 아니면 중간 서버와 통신하는지 알 수 없다. 따라서 클라이언트와 서버의 통신 사이에 보안이나 로드 밸런싱등을 위한 중간 계층을 추가할 수 있다.

 

 

HTTP 응답 상태 코드

---

상태코드	내용
200	클라이언트의 요청을 정상적으로 수행함
201	클라이언트가 어떠한 리소스 생성을 요청, 해당 리소스가 성공적으로 생성됨(POST를 통한 리소스 생성 작업 시)

 

400	클라이언트의 요청이 부적절 할 경우 사용하는 응답 코드
401	클라이언트가 인증되지 않은 상태에서 보호된 리소스를 요청했을 때 사용하는 응답 코드
	(로그인 하지 않은 유저가 로그인 했을 때, 요청 가능한 리소스를 요청했을 때)
403	유저 인증상태와 관계 없이 응답하고 싶지 않은 리소스를 클라이언트가 요청했을 때 사용하는 응답 코드
	(403 보다는 400이나 404를 사용할 것을 권고. 403 자체가 리소스가 존재한다는 뜻이기 때문에)
405	클라이언트가 요청한 리소스에서는 사용 불가능한 Method를 이용했을 경우 사용하는 응답 코드

301	클라이언트가 요청한 리소스에 대한 URI가 변경 되었을 때 사용하는 응답 코드
	(응답 시 Location header에 변경된 URI를 적어 줘야 합니다.)
500	서버에 문제가 있을 경우 사용하는 응답 코드

 

 

REST의 장단점

---

장점

1. 별도의 인프라 구축 필요 없음
- HTTP를 사용하기 때문에 별도의 인프라를 구축할 필요가 없다.

2. 클라이언트와 서버의 분리
- 클라이언트와 서버는 REST API를 통해 정보를 주고 받기 때문에 둘 간의 역할이 명확하게 분리된다.

3. 플랫폼에 독립적
- HTTP를 사용 가능한 환경이라면 플랫폼에 상관없이 사용 가능하다.

4. 쉬운 사용 (직관성)
- 메세지가 자체적으로 무엇을 의미하는지 표현하고 있기 때문에 사용이 쉽다.

단점

1. 표준이 존재하지 않음
- 명확한 표준이 존재하지 않는다. 따라서 REST의 특징을 따르지 않으면서 REST API로 설계되는 이상한 API가 탄생할 수 있으며 관리가 어렵다.

2. HTTP Method의 한계
- HTTP Method를 사용하기 때문에 CRUD라는 단순한 행위의 Method만 지원한다.

3. RDBMS와 맞지 않음
- REST에서는 리소스를 JSON, XML등의 형태로 표현하는데 이는 RDBMS와는 맞지 않는 형태이다. 그래서 NoSQL쪽이 더 선호되는 추세.