REST API란?

REST

REST(Representation State Transfer)는 자원을 이름으로 구분하여 해당 자원의 상태(정보)를 주고 받는 모든 것이다.

자원 : 한 소프트웨어가 관리하는 모든 것 (문서, 이미지 등)

풀어서 설명하지면, URI를 통해 자원을 명시하고 HTTP 메서드 (GET, POST, PUT, DELETE)로 해당 자원에 대한 CRUD Operation을 적용하는 것을 의미한다.

CRUD Operation :
대부분의 컴퓨터 소프트웨어가 가지는 기본적인 데이터 처리 기능

1 ) Create : 리소스 생성 (POST)
2 ) Read : 리소스 조회 (GET)
3 ) Update : 수정 (PUT )
4 ) Delete : 삭제 ( DELETE )

구성 요소

1. 자원 (Resource) : HTTP URI (ex. example.com/posts/rest.html)
2. 자원에 대한 행위 (Verb) : HTTP 메서드 (POST, GET, PUT, DELETE)
3. 표현 (Representation) : HTTP 메시지 (행위의 내용)

특징

1. 인터페이스 일관성 (uniform)

   통일되고 일관성 있는 인터페이스를 통해 URI로 지정된 리소스에 대한 조작을 수행한다.

2. 무상태성 (stateless)

   HTTP 프로토콜 표준을 따르기 때문에, 세션이나 쿠키 등 상태정보를 따로 저장하거나 관리하지 않는다. 때문에 서비스 자유도가 높아지고 구현이 단순해진다.

3. 캐시 처리 가능 (cacheable)

   HTTP 프로토콜의 인프라를 그대로 사용하기 때문에, 캐싱이 가능하다. Last-Modified 태그나 E-Tag를 이용하면 캐싱 구현이 가능하다.

4. 클라이언트 - 서버 구조

   서버는 클라이언트에게 API만 제공하기 때문에, 클라이언트의 컨텍스트(세션, 로그인 정보 등)를 저장할 필요가 없다. 따라서, 각자의 역할 분담이 명확하다.

5. 계층형 구조 (layered system)

   REST 서버는 다중 계층으로 구성될 수 있어 보안, 로드 밸런싱, 암호화 계층 등을 추가할 수 있어 확장성 및 보안 향상이 가능하다.

6. 자체 표현 구조 (self-descriptive)

   REST API 메시지는 별도의 주석이나 문서 없이도 그 자체로 쉽게 이해할 수 있어야 한다.

장점

• HTTP 프로토콜의 인프라를 그대로 사용하기 때문에, 별도의 인프라를 구축할 필요가 없다.
• HTTP 프로토콜 표준을 최대한 활용하여 추가적인 장점을 함께 가져갈 수 있다.
• HTTP 프로토콜을 사용하는 모든 플랫폼에서 사용 가능하다.
• REST API 메시지에 의도가 명시되어있기 때문에, 의도를 쉽게 파악할 수 있다.
• 서비스 디자인에서 생기는 여러 문제들을 최소화한다.
• 서버 / 클라이언트 역할을 명확하게 구분한다.

단점

• 표준이 없기 때문에, 관리가 어렵다.
• HTTP 메서드 형태가 제한적이다.
• 브라우저로 테스트 할 일이 많은 서비스의 경우, 쉽게 수정이 가능한 URL 비해 Header 정보를 처리하는 일이 많기 때문에 전문성이 요구된다.
• 호환성으로 인해 구형 브라우저(익스플로러)에서 동작이 제한적이다.

REST API

API는 데이터와 기능의 집합을 제공하여 프로그램들이 서로 상호작용 할 수 있는 매개체 역할을 한다. 아래와 같은 규칙을 따라, REST를 기반으로 API를 구현할 수 있다.

설계 가이드

기본 규칙

1. URI에 자원의 정보를 표시한다.
2. 자원에 대한 행위는 HTTP 메서드(GET, POST, PUT, DELETE)로 표현한다.

자원을 URI에 표현하기 위해 도큐먼트와 컬렉션을 사용하자.
도큐먼트 (document) : 문서 혹은 객체 - 단수형으로 사용
컬렉션 (collection) : 문서들의 집합 혹은 객체들의 집합 - 복수형으로 사용

GET /posts/rest-api.html

주의할 점

1. URI에서 리소스명을 표시할 때 동사보다 명사를, 대문자보다 소문자를 사용해야한다.

   RFC 3986(URI 문법 형식)은 URI 스키마와 호스트를 제외하고 대소문자를 구별하기 때문에 대문자 사용은 지양하자.

   example.com/Running (X)
   example.com/run (O)
   

2. 계층 간의 관계를 나타내기 위해 슬래시(/)를 사용한다. URI의 마지막에 슬래시를 쓰지 않는다.

   URI의 모든 글자는 리소스의 고유한 식별자다. URI가 다르면 다른 리소스를 가르키고, 반대로 리소스가 다르면 URI도 달라야 한다.

   example.com/animals/cat/ (X)
   example.com/animals/cat (O)
   

3. 밑줄(_) 대신 하이픈(-)을 사용한다.

   밑줄은 잘 보이지 않을 뿐더러, 문자가 가려지기도 한다. 가독성을 위해 하이픈을 사용하자.

   example.com/learn_rest (X)
   example.com/learn-rest (O)
   

4. 파일 확장자를 URI에 표시하지 않는다.

   HTTP Accept header에 표시한다.

   example.com/photo.jpg (X)
   example.com/photo (O)
   

5. URI에 행위를 포함하지 않는다.

   행위는 HTTP 메서드로 표현한다.

   example.com/delete-post/1 (X)
   example.com/post/1 (O)
   

RESTful

RESTful은 REST 아키텍쳐를 구현하는 웹 서비스를 나타내기 위해 사용되는 용어인데, 보통 REST의 설계 가이드를 올바르게 지킨 시스템을 “RESTful하다”라고 말한다. REST를 일부분 따랐다고 해서 모든 서비스가 RESTful한 것은 아니다.

RESTful의 목적은 일관성 있는 컨벤션을 지켜 누구나 이해하기 쉽고 호환성이 높은 API를 만드는 것이다.

정리

1. REST는 웹의 기본 원칙을 따르며, 클라이언트와 서버 간의 상호작용을 간단하고 효율적으로 만들기 위한 아키텍처적인 가이드를 제공한다.
2. REST는 리소스를 고유한 URI로 식별하고 HTTP 메서드(GET, POST, PUT, DELETE)를 사용하여 리소스에 대한 상태를 조작한다.
3. REST 가이드 라인을 올바르게 따른 API는 누구나 이해하기 쉽고 호환성이 높다. 이를 RESTful한 API라고 한다.

Reference

• https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html
• https://meetup.nhncloud.com/posts/92
• https://khj93.tistory.com/entry/네트워크-REST-API란-REST-RESTful이란