[Back-End] REST, REST API, RESTful API

🤔REST vs REST API vs RESTful API

REST : 자원을 이름으로 구분해 해당 자원의 상태(정보)를 주고 받는 모든 것
REST API : REST를 기반으로 서비스 API를 구현한 것
RESTful API : REST의 설계 규칙을 잘 지켜서 설계된 API (REST의 원리를 잘 따르는 시스템)

API (Application Programming Interface)

• 응용 프로그램에서 사용할 수 있도록 운영체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스
• 응용프로그램에서 데이터를 주고 받기 위한 방법으로, 어떤 사이트에서 데이터를 공유할 경우 어떠한 방식으로 정보를 요청해야 하는지, 어떠한 데이터를 제공 받을 수 있을지에 대한 규격

📌REST (Representational State Transfer)

• REST는 자원을 이름으로 구분하여 해당 자원의 상태를 주고받는 모든 것을 의미한다.

• HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고
  HTTP Method(POST, GET, PUT, DELETE, PATCH 등)를 통해
  해당 자원(URI)에 대한 CRUD Operation을 적용하는 것

  Create : 데이터 생성 (POST)
  Read : 데이터 조회 (GET)
  Update : 데이터 수정 (PUT, PATCH)
  Delete : 데이터 삭제 (DELETE)

구성 요소

1. 자원(Resource) : HTTP URI
   • Client는 URI를 이용해 자원을 지정하고 해당 자원의 상태(정보)에 대한 조작을 Server에 요청한다.
   • ex) '/member/:member_id'
2. 자원에 대한 행위(Verb) : HTTP Method
3. 표현 (Representations) : HTTP Message PayLoad
   • Client와 Server가 데이터를 주고받는 형태
   • JSON, XML을 통해 데이터를 주고 받는 것이 일반적

특징

1. Server-Client (서버-클라이언트 구조)

• 자원이 있는 쪽이 Server, 자원을 요청하는 쪽이 Client
  • Server : API 제공, 비즈니스 로직 처리 및 저장
  • Client : 사용자 인증, context (세션, 로그인 정보) 등을 관리
• 역할을 구분함으로써 서로 간의 의존성을 줄인다.

2. Stateless (무상태)

• HTTP 프로토콜은 기본적으로 무상태이다. REST 역시 HTTP를 기본으로 하기 때문에 무상태이다.
• 무상태란 클라이언트의 상태(State)를 서버에 저장하지 않는다는 뜻
  • Client의 context를 Server에 저장하지 않는다.
  • Server는 각각의 요청을 완전히 별개의 것으로 인식하고 처리한다.
  • 각 API 서버는 Client의 요청만을 단순 처리한다.
  • 이전 요청이 다음 요청의 처리에 연관되지 않는다.
  • Server의 처리 방식에 일관성을 부여하고 부담이 줄어든다.

3. Cacheable (캐시 처리 기능)

• HTTP 프로토콜을 그대로 사용하므로 캐싱 기능을 적용할 수 있다.
• 대량의 요청을 효율적으로 처리할 수 있다.
• 캐시 사용을 통해 응답 시간이 빨라지고 성능, 서버의 자원 이용률을 향상시킬 수 있다.

4. Layered System (계층 구조)

• Client는 REST API Server만 호출한다.
• REST Server는 다중 계층으로 구성될 수 있다.
• 보안, 로드 밸런싱, 암호화 등을 위한 계층을 추가하여 구조를 변경할 수 있다.
• Proxy, Gateway와 같은 네트워크 기반의 중간매체를 사용할 수 있다.

5. Code-On-Demand (Optional)

• Server로부터 스크립트를 받아서 Client에서 실행한다.
• 반드시 충족할 필요는 없다.

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

• URI로 지정한 Resource에 대한 요청을 통일되고 한정적인 인터페이스로 수행한다.
• HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하다. 따라서 특정 언어나 기술에 종속되지 않는다.

📌REST API

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

특징

• 각 요청이 어떤 동작이나 정보를 위한 것인지를 그 요청의 모습 자체로 추론이 가능하다.

기본 규칙

1. URI는 정보의 자원을 표현해야 한다.
2. 자원에 대한 행위는 HTTP Method(GET, POST, PUT, PATCH, DELETE)로 표현한다.
3. 행위(Method)는 URI에 포함하지 않는다.

설계 규칙

1. URI는 명사를 사용한다. (동사 사용 X)
2. 슬래시( / )로 계층 관계를 표현한다.
3. URI 마지막에 슬래시 ( / )를 사용하지 않는다.
4. 언더바( _ ) 대신 하이픈( - )을 사용한다.
5. URI는 소문자로만 구성한다.
6. 파일확장자는 URI에 포함하지 않는다.
7. 행위를 포함하지 않는다. (Bad ex. "http://y.com/delete-post/1")
8. HTTP 응답 상태 코드 사용

💡 URI는 정보의 자원만 표현해야 하며, 자원의 행위는 HTTP Method에 명시한다!

📌RESTful API

RESTful이란 REST의 설계 규칙을 잘 지켜서 설계된 API로, REST의 원리를 따르는 시스템을 의미한다.

REST를 사용했다 하여 모두가 RESTful 한 것이 아니라 REST API의 설계 규칙을 올바르게 지킨 시스템을 RESTful하다 말할 수 있다.

- CRUD 기능을 모두 POST로 처리 하는 API
- URI 규칙을 올바르게 지키지 않은 API

위의 예시처럼 REST API의 설계 규칙을 올바르게 지키지 못한 시스템은 REST API를 사용하였지만 RESTful 하지 못한 시스템이라고 할 수 있다.

목적

• 이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것

→ 성능이 중요한 상황에서는 굳이 RESTful한 API를 구현할 필요는 없다!

---

📝면접 대비

Q. RESTful API란 무엇인가요?

A.