REST

REST의 개념 

---

REST란? 

Representational State Transfer의 약자 
웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하는 데이터 송수신 아키텍처 스타일 
네트워크 상에서 Client와 Server 사이의 통신 방식 중 하나 
자원을 이름으로 구분하여 해당 자원의 상태(정보)를 주고 받는 것을 의미 
JSON 혹은 XML을 통해 데이터를 주고 받는 것이 일반적 

 

REST의 구체적인 개념 

• HTTP URI를 통해 자원을 명시하고, HTTP Method를 통해 해당 자원에 대해 CRUD Operation을 적용하는 것을 의미
• 즉, 자원 기반의 구조(ROA) 설계의 중심에 Resource가 있으며, HTTP Method를 통해 Resource를 처리하도록 설계된 아키텍처

 

CRUD Operation

• Create : 생성(POST)
• Read : 조회(GET) 
• Update : 수정(PUT) 
• Delete : 삭제(DELETE) 
• HEAD : header 정보 조회(HEAD) 

 

REST의 장단점 

---

장점 

• HTTP 프로토콜의 인프라를 그대로 사용하므로, 별도의 인프라가 필요 없음 
• HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능함
• REST API 메시지가 의도하는 바를 명확하게 나타내므로 의도를 쉽게 파악할 수 있음 
• 서버와 클라이언트의 역할을 명확하게 분리함 

 

단점 

• 사용할 수 있는 메소드가 한정적
• 구형 브라우저가 아직 제대로 지원해주지 못하는 부분이 존재(PUT,DELETE 사용 불가, pushState 지원 안함) 

 

REST가 필요한 이유? 

• 최근의 서버 프로그램은 다양한 브라우저, 스마트폰과 같은 모바일 디바이스에서 통신이 가능해야함 
• 즉, 멀티 플랫폼 지원을 위해 등장

 

 

REST 구성 요소 

---

Resource

• 모든 자원에 고유한 ID가 존재하며, 이 자원은 서버에 존재 
• 자원을 구별하는 ID는 '/users/:user_id'와 같은 HTTP URI 
• Client는 URI를 통해 자원을 지정하고, 서버에게 요청함 

 

Verb

• HTTP 프로토콜의 Method를 사용함 

 

Representation of Resource 

• Client가 서버에게 요청하면, 이에 적절한 응답(Representation)을 보냄 
• REST는 JSON,XML,TEXT,RSS등 여러 형태의 Representation으로 나타냄
• 보통 JSON, XML을 통해 데이터를 주고 받음 

 

REST의 특징 

---

Server-Client 

• REST Server : API를 제공하고, 비즈니스 로직 처리 및 저장을 책임 
• Client : 사용자 인증이나 context(세션, 로그인 정보) 등을 직접 관리하고 책임짐

 

Stateless 

• HTTP 프로토콜은 Stateless Protocol이므로 REST 역시 무상태성을 가짐 
• Client의 context를 Server에 저장하지 않음 
• Server는 각각의 요청을 완전히 별개의 것으로 인식하고 처리함 

 

Cacheable 

• 웹 표준 HTTP 프로토콜을 그대로 사용하므로 웹에서 사용하는 기존의 인프라를 그대로 활용 
• 즉, HTTP가 가진 가장 강력한 특징 중 하나인 캐싱 기능을 활용 가능 

 

Layered System(계층화) 

• Client는 REST API Server만 호출 
• REST server는 다중 계층으로 구성 
• API Server는 순수 비즈니스 로직만 수행하고, 그 앞단에 보안, 로드밸런싱, 암호화, 사용자 인증 등을 추가하여 구조상의 유연성을 줄 수 있음 
• PROXY, 게이트웨이 같은 네트워크 기반의 중간 매체를 사용할 수 있음

 

Uniform Interface(인터페이스 일관성) 

• URI로 지정한 Resource에 대한 조작을 통일되고 한정적인 인터페이스로 수행 
• 특정 언어나 기술에 종속되지 않음

 

REST API의 개념 

---

API 

데이터와 기능의 집합을 제공하여 컴퓨터 프로그램간 상호작용을 촉진하며, 서로 정보를 교환 가능 하도록 하는 것 

REST API 

REST 기반으로 서비스 API를 구현한 것 
최근 Open API(구글 맵, 공공 데이터), 마이크로 서비스(하나의 큰 애플리케이션을 여러 개의 작은 애플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍처) 등을 제공하는 업체 대부분 REST API를 제공 

 

REST API의 특징 

• HTTP를 지원하는 프로그램 언어로 클라이언트, 서버를 구현할 수 있음 

 

REST API 설계 기본 규칙  

---

 

REST API 설계 기본 규칙 

1. 슬래시 구분자(/)는 계층 관계를 나타내는데 사용한다.

• http://restapi.example.com/users/vipusers

2. URI 마지막 문자로 슬래시(/)를 포함하지 않는다. 

• URI에 포함되는 모든 글자는 유일한 식별자로 사용되야 하며, URI가 다르다는 것은 리소스가 다르다는 것 
• 혼동을 주지 않도록 절대로 마지막에 슬래시를 포함하지 않는다. 

3. 하이픈(-)은 URI 가독성을 높이는데 사용한다. 

4. 밑줄(_)은 URI에 사용하지 않는다.

5. URI 경로에는 소문자를 사용하도록 한다.

6. 파일 확장자는 URI에 표현하지 않는다.

• REST API에서는 메시지 바디 내용의 포맷을 나타내기 위한 파일 확장자를 URI에 표시하지 않는다.
• 대신 Accept header를 사용한다.
• Ex) GET / members/soccer/345/photo HTTP/1.1 HOST : restapi.example.com Accept : image/jpg

7. 리소스 간에는 연관 관계가 있는 경우

• /리소스명/리로스 ID/관계가 있는 다른 리소스명 
• Ex) GET : /users/{userid}/devices 

 

REST API 설계 예시  

 

 

응답 상태 코드 

1XX : 전송 프로토콜 수준의 정보 교환
2XX : 클라이언트 요청 성공적으로 수행
3XX : 클라이언트는 요청을 완료하기 위해 추가적인 행동을 취해야 함 
4XX : 클라이언트의 잘못된 요청
5XX : 서버쪽 오류로 인한 상태코드

 

REFERENCE

https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html

[Network] REST란? REST API란? RESTful이란? - Heee's Development Blog

https://www.slideshare.net/Byungwook/rest-api-60505484

REST API 설계