[HTTP 통신] REST(Representational State Transfer)

REST(Representational State Transfer)란?
HTTP 프로토콜 기반으로 URI를 통해 자원을 명시하고 HTTP Method(GET, POST, PUT, DELETE, HEAD)를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것을 의미합니다.
자원 기반의 구조(ROA, Resource Oriented Architecture) 설계의 중심에 Resource가 있고 HTTP Method를 통해 Resource를 처리하도록 설계된 아키텍쳐입니다.
이미지, 텍스트, DB 내용 등 모든 자원에 고유한 ID인 HTTP URI를 부여하기 때문에 URI만 보고도 Client와 Server가 어떤 자원을 요청하고 있는지를 직관적으로 알 수 있습니다.

 

• 장점

1. HTTP 프로토콜의 인프라를 그대로 사용하므로 REST API 사용을 위한 별도 인프라를 구축할 필요가 없어 운용에 편리합니다.
2. HTTP 프로토콜의 표준을 최대한 활용하므로 HTTP 프로토콜의 장점을 함께 가져갈 수 있습니다.
3. HTTP 표준 프로토콜을 따르는 모든 플랫폼에서 사용 가능하므로 확장성과 재사용성이 높습니다.
4. REST API 메세지가 의도하는 바를 명확하게 나타내므로 직관적으로 파악할 수 있습니다.
5. 서버와 클라이언트 역할을 명화갛게 분리합니다.

 

• 단점

1. 사용할 수 있는 메서드가 4가지로 제한적입니다.
2. PUT, DELETE 메서드를 지원하지 않은 구형 브라우저의 경우 호환이 되지 않을 수 있습니다.(인터넷 익스플로어)

 

 

• CRUD Operation

CRUD Operation을 수행할 때 클라이언트는 자원에 대한 요청에 따라 올바른 HTTP Method를 지정해줘야 합니다.

1. Create 생성: POST
2. Read 조회: GET
3. Update 수정: PUT
4. Delete 삭제: DELETE
5. HEAD 헤더 정보 조회: HEAD

 

 

• REST 구성요소

1. 자원(Resource): URI

모든 자원에는 고유한 ID가 존재하고, 자원은 Server에 존재합니다.

 

2. 행위(Verb): HTTP Method

클라이언트는 URI를 이용해서 자원을 지정하고 자원의 상태에 대한 조작을 HTTP Method로 지정해 서버에 요청합니다.

 

3. 표현(Representations)

서버 응답의 표현입니다.

서버는 클라이언트가 지정한 URI에 대한 요청을 처리하고 응답을 제공하며 JSON, XML 등의 형태로 표현합니다.

 

 

• REST의 특징

1. Client-Server 구조

Client-Server Architecture이므로 유저 인터페이스와 데이터를 저장하는 서버가 분리되어 있어서 의존성이 줄어듭니다.

REST 서버는 API를 제공하고 클라이언트는 사용자 인증, 컨텍스트(세션, 로그인 정보) 등을 직접 관리하는 구조로 각각 역할이 명확하게 구분됩니다.

 

2. 무상태성 Stateless

 

서버에 세션/쿠키 정보나 상태를 별도로 저장하고 관리하지 않기 때문에 Stateless하다는 특징이 있습니다.

따라서 이전 요청이 다음 요청 처리에 연관되지 않기 때문에 서버는 각각의 요청을 완전히 별개의 것으로 인식하고 처리합니다.

그래서 서비스의 자유도가 높아지고 서버에서 불필요한 정보를 관리하지 않으므로 구현이 단순해집니다.

 

3. 캐시 가능 CacheableREST의 가장 큰 특징은 HTTP라는 기존 웹 표준을 그대로 사용하기 때문에 웹에서 사용하는 기존 인프라를 그대로 활용합니다.따라서 HTTP가 가진 캐싱 기능이 적용되어 Last-Modified 태그나 E-Tag를 이용하면 캐싱 구현이 가능합니다.

 

캐싱이 가능한 데이터라면 클라이언트단에서 캐시에 데이터를 저장해두고 같은 요청을 처리할 때 캐시를 사용해 데이터를 꺼내올 수 있어 성능을 향상시킬 수 있습니다.

 

4. 계층형 구조 Layered System

 

REST 서버는 다중 계층으로 구성될 수 있으며 보안, 로드 밸런싱, 암호화 계층을 추가해서 확장성과 보안성을 향상시킬 수 있습니다.

또한 PROXY, 게이트웨이와 같은 네트워크 기반의 중간매체를 사용할 수 있습니다.

클라이언트는 이런 계층을 모르더라도 서버를 호출할 수 있으며 서버는 다중 계층으로 구성될 수 있습니다.

 

* 로드 밸런싱: 서버에 가해지는 부하를 분산하는 장치, 여러대의 서버를 두는 Scale Out 방식

 

5. Code-On-Demand(선택사항)

서버로부터 스크립트를 받아 클라이언트에서 실행할 수 있다.

 

6. 인터페이스 일관성 Uniform Interface

 

HTTP 표준에만 따른다면, 특정 언어나 기술에 종속되지 않고 모든 플랫폼에 사용할 수 있으며, URI로 지정한 리소스에 대한 조작이 가능한 아키텍처 스타일입니다.

 

7. 자체 표현 구조 Self-descriptiveness

REST API 메세지만 보고도 쉽게 이해할 수 있는 자체 표현 구조로 되어 있습니다.

 

 

• RESTful API 설계 기본 규칙

자원은 동사보다는 명사를 사용하며, 영어 소문자 복수형을 사용해 표현합니다.

언더바(_) 대신 하이픈(-)을 사용해서 공백을 제거하고 가독성이 좋게 합니다.

확장자 사용을 지양하고 대신에 확장자는 헤더에 담습니다. (Accept: text/csv)

CRUD, 자원에 대한 행위에 관한 동사 표현이 들어가면 안됩니다.

슬래시 구분자(/)로 자원의 계층 관계를 나타내며, URI 마지막에 /를 포함하지 않습니다.

 

 

* 참고: URI와 URL의 차이

https://www.charlezz.com/?p=44767

URI랑 URL 차이점이 뭔데? | 찰스의 안드로이드

 

 

• 응답 코드

• 200 : 클라이언트 요청 정상수행 (응답에 대한 메시지가 포함)
• 201 : 리소스 생성 요청에 대한 정상처리 
• 202 : 리소스 생성 요청이 비동기적으로 처리될 때 사용
• 204 : 클라이언트 요청 정상수행 (응답에 대한 메시지 미포함, 삭제요청 따위에 사용)
• 400 : 클라이언트 요청이 부적절할 때 사용 (부적절한 이유를 응답 Body에 넣어줘야 함)
• 401 : 클라이언트가 인증되지 않은 상태에서 보호된 리소스를 요청할 때 사용
• 403 : 클라이언트가 인증상태와 무관하게 응답하고 싶지 않은 리소스를 요청할 때 사용 (400 사용을 권장)
• 404 : 클라이언트가 요청한 리소스가 존재하지 않을 때 사용
• 405 : 클라이언트가 불가능한 메소드를 사용했을 때

---

REST API와 RESTful

REST API는 REST 기반으로 서비스 API를 구현한 것을 말합니다.

RESTful은 REST 원리를 따르는 시스템을 'RESTful하다'라고 표현합니다.

RESTful은 REST를 REST답게 쓰기 위한 방법이고 누군가 공식적으로 정의한 표준이 존재하는 것은 아닙니다.

 

---

참고

• http://www.incodom.kr/REST

REST - 인코덤, 생물정보 전문위키