REST, RESTful, RESTful API

REST(Representational State Transfer)

• 소프트웨어 아키텍처 스타일의 하나로, 분산 시스템에서 리소스를 정의하고 관리하기 위한 웹 서비스 설계 원칙을 의미한다.
• REST는 클라이언트와 서버 간의 통신을 위한 표준화된 방법을 제공하여 서비스의 유연성, 확장성, 성능 등을 향상시킨다.
• Representational State Transfer의 약자로 자원을 표현하고 상태를 전송하는 웹 아키텍처 스타일이다. 이를 통해 클라이언트와 서버 간에 데이터를 주고받을 수 있으며 주로 HTTP 프로토콜을 통해 이루어진다.

 

RESTful API란?

• REST API(Representational State Transfer Application Programming Interface)는 REST 원칙에 따라 설계된 API를 가르킨다. 즉, RESTful한 API는 REST의 원칙을 준수하여 구현된 API를 말한다.
• HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고, HTTP Method(POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것을 의미한다.
• 최근 서버 프로그램은 다양한 브라우저(안드로이폰, 아이폰과 같은 모바일 디바이스)에서 통신을 할 수 있어야 한다. 이러한 멀티 플랫폼에 대한 지원을 위해 서비스 자원에 대한 아키텍처를 세우고 이용하는 방법을 모색한 결과 REST가 사용되는 것!
  

 

RESTful API의 주요 특징

1. 자원(URI): 각 자원은 고유한 URI(Uniform Resource Identifier)로 식별된다.
2. 행위(HTTP 메소드): HTTP 메소드(GET, POST, PUT, DELETE 등)를 사용하여 자원에 대한 행위를 정의한다.
3. 표현: 클라이언트와 서버 간에 자원의 표현을 주고받는다. 주로 JSON 또는 XML 형식을 사용한다.

CRUD Operation

• Create : 생성(POST)
• Read : 조회(GET)
• Update : 수정(PUT)
• Delete : 삭제(DELETE)
• HEAD: header 정보 조회(HEAD)

HTTP 메소드

• GET: 리소스를 조회하기 위해 사용된다. 클라이언트가 서버에게 데이터를 요청할 때 사용
• POST: 새로운 리소스를 생성하기 위해 사용된다. 데이터를 서버로 보낼 때 사용
• PUT: 주어진 URI에 리소스를 저장한다. 해당 URI에 대한 데이터를 전체적으로 갱신할 때 사용
• DELETE: 특정 리소스를 삭제하기 위해 사용
• PATCH: 리소스의 일부를 수정하기 위해 사용

 

URI 설계 (자원을 어떻게 표현할지 URI를 설계하는 방법)

• 리소스를 나타내는 URI는 명확하고 직관적이어야 한다.
• 각 리소스는 고유하게 식별되어야 한다.
• RESTful한 URI는 계층적이고 직관적인 구조여야 한다.
  • Ex) /users/123과 같은 형태로 사용자 리소스에 접근할 수 있어야 한다.

상태 코드

• 2xx: 성공
• 3xx: 리다이렉션
• 4xx: 클라이언트 오류 ex) 리소스를 찾지 못했을 때 -> 404 반환
• 5xx: 서버 오류

 

인증 및 보안 (API 보안을 위한 기본적인 인증 방법 + 보안 관련)

• HTTPS를 통한 통신을 보장하여 데이터의 안전성을 유지한다.
• JWT(Json Web Token)나 OAuth 등의 인증 방법을 사용하여 사용자 인증을 수행한다.

 

페이징과 필터링 (대용량 데이터를 다룰 때)

• 대용량 데이터를 다룰 때 필요한 페이징 기법을 사용하여 데이터를 페이지 단위로 나누어 전송한다. -> 상태 관리!
• 필터링은 사용자가 원하는 조건에 맞는 데이터만 검색할 수 있도록 하는 기능, 일반적으로 쿼리 매개변수를 사용하여 구현된다.

 

REST의 장단점

 

장점

• HTTP 프로토콜의 인프라를 그대로 사용하므로 REST API 사용을 위한 별도의 인프라를 구출할 필요가 없음
• HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용 가능
• Hypermedia API의 기본을 지키면서 범용성을 보장함
• REST API 메시지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악할 수 있다.
• 여러가지 서비스 디자인에서 생길 수 있는 문제를 최소화한다.
• 서버와 클라이언트의 역할을 명확하게 분리한다.

단점

• 표준이 존재하지 않음
• HTTP Method 형태가 제한적임
• 브라우저를 통해 테스트할 일이 많은 서비스라면 쉽게 고칠 수 있는 URL보다 Header 값이 왠지 더 어렵게 느껴진다.
  
  

결론

REST : 웹 서비스 설계 원칙을 의미

REST API : 이러한 원칙을 따라 설계된 API를 의미

RESTful API : REST의 원칙을 따라 구현된 API를 의미