[ Network ] REST란? / Rest API와 Restful API의 차이점 / REST 규칙

 

REST(REpresentational State Transfer)?

• 웹에 존재하는 모든 자원(문서, 이미지, 동영상 등)에 고유한 URI를 부여해 활용하는 것으로 자원을 정의하고 자원에 대한 주소를 지정하는 방법론
• 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에 웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일이다.
• HTTP 메소드(POST, GET, PUT, DELETE)를 통해 CRUD(Create, Read, Update, Delete) 연산을 수행한다.
• 서버와 클라이언트가 데이터를 주고받는 형식은 json, xml, text, rss 등이 있으며 Key와 Value를 활용하는 json을 주로 사용한다.
• 자원(Resource) : URI, 행위(Verb) : HTTP Method, 표현(Representatiohn of Resource) 세 가지 구성 요소를 갖는다.
• 네트워크 상에서 클라이언트와 서버 사이의 통신 방식 중 하나로 자원을 요구하는 쪽(브라우저)이 클라이언트이고 자원을 가지고 있는 쪽이 서버이다.
• 다양한 클라이언트(모바일 디바이스 등)의 등장으로 멀티 플랫폼을 지원하는 소비스 자원에 대한 아키텍처의 대안으로 REST가 관심받는다.
• Node.js에서는 Express 모듈을 이용해 Restful API를 구성한다. Express 모듈은 웹 프레임워크로 HTTP를 기반으로 통신하기 때문에 웹 서버 구축과 API 서버 구축 모두 사용된다.

- HTTP 메소드

GET	Read : 정보 요청, URI가 가진 정보를 검색하기 위해 서버에 요청한다.
POST	Create : 정보 입력, 클라이언트에서 서버로 전달하려는 정보를 보낸다.
PUT	Update : 정보 업데이트, 주로 내용을 갱신하기 위해 사용한다.
DELETE	Delete : 정보 삭제, (안정성 문제로 대부분 서버에서 비활성한다.)

* HTTP  메소드는 사람의 이해를 돕기 위해 구별하기 위한 용도이므로 POST로 데이터를 지우거나 DELETE로 생성을 하게 만들 수도있다.

 

 

REST 규칙

Uniform Interface

• 일관성있는 인터페이스로 URI로 지정한 자원에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일.
• HTTP 표준 프로토콜에만 따른다면 모든 플랫폼(특정 OS나 특정 언어에 종속된 것이 아닌)에서 사용이 가능하다.
  

Client-Server

• 자원이 있는 쪽이 서버, 자원을 요청하는 쪽이 클라이언트로 클라이언트-서버 구조를 갖는다.
• REST 서버는 API를 제공하고 클라이언트는 사용자 인증, 컨텍스트(세션, 로그인 정보 등)을 직접 관리한다.
• 클라이언트와 서버의 역할이 구분되어 개발 내용이 명확해지고 의존성이 줄어든다.

Stateless

• HTTP 프로토콜이 Stateless Protocol인 것과 마찬가지로 REST도 무상태성을 갖는다.
• 클라이언트의 세션과 쿠키같은 컨텍스트를 서버에 저장하지 않으므로 서버 구현이 단순해진다.
• 클라이언트의 요청을 각각 별개의 것으로 인식하며 단순 처리하게 처리만 하면 된다.

Cacheable

• 웹 표준을 따라 웹의 인프라를 사용할 수 있으므로 캐싱 기능을 적용할 수 있다.
• HTTP에서 사용하는 Last-Modified나 E-Tag를 사용해 구현할 수 있다.
• 일반적인 서비스에서 조회 기능이 많이 사용된다는 점에서 캐싱 기능이 용량과 성능면에서 이점이 있다.
• 응답시간이 빨라지고 트랜잭션이 발생하지 않아 대용량 요청을 효율적으로 처리한다.

* 캐시 : 자주 사용하는 문서의 사본을 자동으로 보관하여 웹 요청이 캐시에 도착할 때 로컬 사본이 존재하면 문서가 서버쪽이 아닌 캐시로부터 제공된다.

Layered System

• 클라이언트와 서버가 분리되어 중간에 프록시 서버, 로드 밸런싱, 암호화 계층 등 중간매체를 사용해 자유도를 높일 수 있다.
• 클라이언트는 API만 호출하므로 직접 통신하는 것 인지 중간 서버와 통신하는지 알 수 없다.

Self-Descriptiveness

• JSON형태의 메시지를 통해 내용을 직관적으로 이해할 수 있다.
• Rest API 메시지 만으로 그 요청이 어떤 행위인지 알 수 있는 자체 표현 구조로 되어있다.

REST API?

• REST의 특징을 기반으로 API를 제공하는 것
• 공공데이터, 구글 맵, 마이크로 서비스 등 대부분이 REST API를 통해 제공한다.
• HTTP 표준을 기반으로 구현하기 때문에 HTTP를 지원하는 프로그램 언어를 사용하여 클라이언트와 서버를 구현할 수 있다.

RESTful API?

• REST의 6가지 규칙을 잘 지켜서 설계된 API를 RESTful API라고 한다.
• 이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것을 목적으로 성능이 중요하다면 꼭 RESTful하게 구현할 필요는 없다.

* 설계 시 주의사항(경로 네이밍 규칙)

1. URI는 정보의 자원을 표현해야 한다.(리소스명은 동사가 아닌 명사를 사용한다)
2. 자원의 행위는 HTTP 메소드(GET, POST, PUT, DELETE)로 표현한다.
3. 슬래시(/)는 계층 관계를 나타낼 때 사용한다.
4. 소문자를 사용한다.
5. 밑줄(_)은 사용하지 않고 하이픈(-)을 사용한다.
6. 확장자(.txt, .png 등)를 사용하지 않는다.
7. URI의 마지막에 슬래시(/)를 포함하지 않는다.