[Network] REST API란? (feat. 원칙과 네이밍 규칙) (What is a REST API?)

REST란?

REST는 Representational State Transfer의 약자로 직역하면 "대표로 상태를 전송하는 것"이다.

제대로 된 의미는 "데이터의 이름으로 상태를 구분하여 전송하는 방식" 이다.

예를 들어 쉽게 설명하면 아래와 같다.

데이터의 이름

"이거 유저에 대한 데이터야" -> user (user라고 이름을 지어 유저 데이터라고 알려줌)

상태

"나 데이터 생성할거야" -> Create (데이터를 생성한다고 알려줌)

전송

"유저 데이터 생성해줘" -> Create user (유저 데이터를 생성해 달라고 요청함)

이와 같이 데이터의 이름으로 상태를 구분하여 전송하는 방식이다.

---

사용하는 이유

그렇다면 REST API를 사용하는 무엇일까?

가장 대표적인 이유는 "HTTP 프토토콜" 이라고 생각한다.

REST API는 HTTP 프로토콜 인프라를 그대로 사용하기 때문에 HTTP를 따르는 모든 플랫폼에서 사용이 가능하다.

즉, 웹의 장점을 최대한 살릴 수 있는 아키텍쳐 스타일이다.

또한 HTTP의 특징과 같이 요청에 대한 것을 명확하게 밝히기 때문에 의도를 파악하기 쉽고 서버와 클라이언트의 역할을 명확히 나눌 수 있다.

---

원칙

REST API를 구현하기 위해선 몇 가지 원칙을 따라야 한다.

1. Uniform Interface

데이터를 식별 가능하게 해야한다는 원칙이다.

구체적으로 URL만 보고도 어느 데이터를 어떤 상태로 전송해야 하는지 구별할 수 있어야 한다.

예를 들면 www.github.com/fomagran/repositories <= 깃헙 fomagran의 레포지토리를 의미하는 것을 알 수 있다.

2. Client Server

클라이언트와 서버는 반드시 분리되어야 하며, 클라이언트는 데이터를 서버에 요청하고 서버는 클라이언트의 요청에 따른 데이터를 응답해야 한다.

3. Stateless

HTTP 프로토콜을 따르기 때문에 HTTP 특징과 같이 상태를 저장하지 않으며, 요청에 모든 정보가 담겨 한 번에 전송해야 한다.

4. Cacheable

요청을 통해 보내는 자료들은 저장되어야 한다.

이를 통해서 저장된 자료들을 주고 받을 때 속도를 향상시킬 수 있다.

5. Layered System

요청된 정보를 검색하는데 계층 구조로 분리되어 있어야 한다.

중간 서버 등을 둬 서버 확장성을 보장한다.

6. Code on Demand

보통 서버는 XML이나 JSON으로 응답하지만, 필요한 경우 코드 자체를 데이터로 클라이언트에 전달할 수 있다.

---

URL 네이밍 규칙

RESTful하게 서비스를 제공하려면 따라야 하는 몇 가지 규칙이 있다.

*RESTful - REST의 규칙을 지켜 제공하는 웹 서비스 방식을 의미한다.

1. 명사를 사용한다.

나쁜 예

www.fomagran.com/get-users

좋은 예

www.fomagran.com/users

2. 소문자를 사용한다.

나쁜 예

www.fomagran.com/Users

좋은 예

www.fomagran.com/users

3. 복수형을 사용한다.

나쁜 예

www.fomagran.com/user

좋은 예

www.fomagran.com/users

4. 구분자는 "-"(하이픈)을 사용한다. (카멜 케이스도 허용되지 않음)

나쁜 예

www.fomagran.com/very_good_users

www.fomagran.com/veryGoodUsers

좋은 예

www.fomagran.com/very-good-users

5. url의 마지막엔 슬래쉬를 포함하지 않음

나쁜 예

www.fomagran.com/very-good-users/

좋은 예

www.fomagran.com/very-good-users

6. 파일 확장자는 포함하지 않음

나쁜 예

www.fomagran.com/photos/image.jpg

좋은 예

www.fomagran.com/photos/image