REST API

REST란?

Representational State Transfer의 약자이다.

REST는 분산 시스템 설계를 위한 아키텍처 스타일이다. 즉 제약 조건의 집합이다.

HTTP를 통해 통신을 할 때 HTTP가 원래 가지고 있는 의미를 잘 활용하는 것을 목표로 한다.

---

API란?

Application Programming Interface의 약자이다.

웹 API는 웹 애플리케이션 개발에서 다른 서비스에 요청을 보내고 응답을 받기 위해 정의된 명세를 일컫는다.

---

REST API란?

말 그대로 REST + API이다. REST 형식을 지키며 HTTP를 통해 CRUD를 실행하는 WEB API를 뜻한다.

웹 애플리케이션이 제공하는 각각의 데이터를 resource, 즉 자원으로 간주하고 각각의 자원에 고유한 URI(Uniform Resource Identifier)를 할당함으로써 이를 표현하는 API를 정의하기 위한 소프트웨어 아키텍처 스타일이다.

---

REST가 필요한 이유?

1. 분산 시스템

거대한 애플리케이션을 모듈, 기능별로 분리하기 쉬워졌다. RESTful API를 서비스하기만 하면 어떤 다른 모듈 또는 애플리케이션들이라도 RESTful API를 통해 상호 간에 통신을 할 수 있기 때문이다.

2. 다양한 클라이언트

서버 프로그램은 다양한 브라우저, 모바일 디바이스 등에서도 통신을 할 수 있어야 한다. 

RESTful API를 사용하면 데이터만 주고받기 때문에 다양한 클라이언트에서 무리 없이 데이터를 이용할 수 있다.

---

REST의 제약 조건

1)  Client - Server 구조 : 서버는 API 제공, 클라이언트는 여러 정보를 직접 관리하는 구조로 각각의 역할이 구분되기 때문에 개발해야 할 내용이 명확해지고 서로 간의 의존성이 줄어든다.

 

2) Stateless(무상태) : 각 요청 간 클라이언트의 콘텍스트가 서버에 저장되어서는 안 된다. 즉 서버는 작업을 위한 클라이언트의 상태 정보를 따로 저장하고 관리하지 않는다. 따라서 서버는 들어오는 요청만을 단순히 처리하면 된다.

 

3) Cacheable(캐시 처리 기능) :  HTTP가 가진 캐싱 기능이 사용 가능해야 한다.

 

4) Uniform interface(인터페이스 일관성) : 일관적인 인터페이스로 분리되어야 한다. 즉 Uniform interface는 URI로 지정한 resource에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일이다.

Uniform interface에는 self-descriptive messages와 HATEOAS가 있다.

 

self-descriptive messages란 메시지가 스스로 설명되어야 한다는 것이다. 즉 메시지의 모든 요소는 메시지만 보고 그 뜻을 알아야 한다는 것이다.  자세한 내용은 여기에 나와있다.

 

HATEOAS란 hypermedia as the engine of application state의 약자이다. 즉 애플리케이션의 상태는 Hyperlink를 이용해서 전이가 되어야 한다는 뜻이다. 모든 접근 가능한 자원들은 Hyperlink를 통해 접근해야 한다.

 

5) Layered System(계층화 시스템) :  서버는 중계 서버(Proxy, Gateway)나 로드 밸런싱(부하 분산), 공유 캐시 등을 이용하여 확장성 있는 시스템을 구현할 수 있다.

 

6) Code-On-Demand : 서버에서 자바 애플릿이나 자바스크립트의 제공을 통해 클라이언트가 실행시킬 수 있는 로직을 전송하여 기능을 확장시킬 수 있다.

 

위의 조건들을 잘 준수하면서 설계된 API를 RESTful 한 API라고 표현한다.

---

REST API 설계

REST의 구성 요소

1. 자원 - URI 

모든 자원은 고유한 ID가 존재하고, 이 자원은 서버에 존재한다.

클라이언트는 URI를 통해 서버로부터 자원을 요청한다.

 

2. 행위 - HTTP Method

자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE)로 표현한다.

 

3. 표현 - 응답 코드 

클라이언트가 자원의 상태에 대해 요청을 하면 서버는 적절한 응답 코드를 보낸다.

하나의 Resource는 여러 형태의 표현으로 나타내어질 수 있다. 

xml, json 등으로 전달할 수 있다.

---

REST API의 중심 규칙

1. URI는 정보의 자원을 표현해야 한다.

• URI 설계 시 주의점

1)  '/ ' 는 계층 관계를 나타내는 데 사용한다.

2) URI 마지막 문자로 ' / '를 삽입하지 않는다.

3) ' - ' 는 가독성을 높이고 ' _ ' 는 사용하지 않는다.

4) 소문자를 사용한다.

5) 확장자는 포함하지 않는다.

6) collection과 document의 개념을 이용하여 표현한다. collection은 문서들의 집합, 객체들의 집합이라고 생각하면 되고 document는 문서라고 생각하면 된다. 

예를 들어 

https://www.instagram.com/stories/youngji_02

위 URL에서 stories라는 collection과 youngi_02라는 document로 표현되고 있다.

collection은 복수로 사용되고 document는 단수로 사용된다.

 

2. 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE)로 표현한다.

메소드 종류	설명
GET	GET을 통해 자원을 조회한다. 자원을 조회하고 해당 도큐먼트에 대한 정보를 가져온다.
POST	POST를 통해 해당 URI를 요청하면 자원을 생성한다.
PUT	PUT을 통해 자원을 수정한다,
PATCH	PATCH를 통해 자원의 일부를 수정한다.
DELETE	DELETE를 통해 자원을 삭제한다.

 

 

 

 

 

 

REFERENCE:
https://ecsimsw.tistory.com/entry/REST-API-Self-descriptive%EC%99%80-HATEOS-%EB%8C%80%EB%B6%80%EB%B6%84-%EB%AA%BB-%EC%A7%80%ED%82%A4%EA%B3%A0-%EC%9E%88%EB%8A%94-%EC%A0%9C%EC%95%BD%EC%A1%B0%EA%B1%B4
https://meetup.toast.com/posts/92
https://velog.io/@banjjoknim/REST-API-%EC%84%A4%EA%B3%84-%EB%B0%8F-%EA%B5%AC%ED%98%84
https://ko.wikipedia.org/wiki/REST
https://sookiwi.com/posts/tech/2018/11/11/Is-it-okay-with-such-REST-APIs/
https://joomn11.tistory.com/26
https://shyvana.tistory.com/7
https://velog.io/@modsiw/REST%EC%99%80-REST-API%EB%9E%80