[BE] REST, REST API, RESTful, 그리고 Retrofit 이해하기

REST (Representational State Transfer)

정의

• 웹 기반 시스템 설계의 핵심 소프트웨어 아키텍처 원칙 중 하나로, 자원(Resource)의 상태(정보)를 표현(Representation)을 통해 클라이언트와 서버가 통신하는 방식을 정의합니다.
• 기본적으로 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에 웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일
• 자원을 이름(자원의 표현)으로 구분하여 해당 자원의 상태(정보)를 주고 받는 모든 것을 의미한다.
  즉, 자원(resource)의 표현(representation) 에 의한 상태 전달
  • 자원(resource)의 표현(representation)
    • 자원: 해당 소프트웨어가 관리하는 모든 것ex) 문서, 그림, 데이터, 해당 소프트웨어 자체 등
    • 자원의 표현: 그 자원을 표현하기 위한 이름ex) DB의 학생 정보가 자원일 때, ‘students’를 자원의 표현으로 정한다.
  • 상태(정보) 전달
    • 데이터가 요청되어지는 시점에서 자원의 상태(정보)를 전달한다.
    • JSON 혹은 XML를 통해 데이터를 주고 받는 것이 일반적이다.
• HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고, HTTP Method(POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것을 의미
  • 즉, REST는 자원 기반의 구조(ROA, Resource Oriented Architecture) 설계의 중심에 Resource가 있고 HTTP Method를 통해 Resource를 처리하도록 설계된 아키텍쳐
  • 웹 사이트의 이미지, 텍스트, DB 내용 등의 모든 자원에 고유한 ID인 HTTP URI를 부여한다.

 

목적

• 웹의 분산 환경에서 통합적이고 간결한 인터페이스를 제공하여 시스템 간 상호 작용을 용이하게 합니다.

특징

• Server-Client(서버-클라이언트 구조)
  • 자원이 있는 쪽이 Server, 자원을 요청하는 쪽이 Client
    • REST Server: API를 제공하고 비즈니스 로직 처리 및 저장을 책임진다.
    • Client: 사용자 인증이나 context(세션, 로그인 정보) 등을 직접 관리하고 책임진다.
  • 서로 간 의존성이 줄어든다.
• 무상태성(Statelessness)
  • HTTP 프로토콜은 Stateless Protocol이므로 REST 역시 무상태성을 갖는다. 
  • 각 요청 간 클라이언트의 상태 정보가 서버에 저장되지 않으므로 세션과 쿠키와 같은 context 정보를 신경쓰지 않아도 되므로 구현이 단순해진다.
• 캐시 가능성(Cacheability)
  • HTTP가 가진 캐싱 기능을 사용할 수 있어 응답시간 단축 및 대역폭 절약이 가능합니다.
• 계층화(Layered System)
  • 클라이언트는 서버를 직접 호출하는 것이 아닌, 대리 서버를 통해 간접적으로 요청을 보낼 수 있습니다.
• 코드 온 디맨드(Code on Demand, 선택적)
  • 서버로부터 실행 가능한 코드를 클라이언트에 전송하여 기능을 일시적으로 확장할 수 있습니다.
• 인터페이스 일관성(Uniform Interface)
  • URI로 지정한 Resource에 대한 조작을 통일되고 한정적인 인터페이스로 수행한다.
  • HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하다.

장단점

• + 확장성 및 유연성이 높고, 간결하여 개발자가 이해하고 사용하기 쉽습니다.(HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능)
• + HTTP 프로토콜에 기반하여 웹 인프라를 그대로 활용할 수 있어 REST API 사용을 위한 별도의 환경을 구축할 필요가 없습니다.
• - 무상태성으로 인한 상태 관리의 어려움이 있을 수 있습니다.
• - REST 자체가 통신 방법에 대한 가이드라인을 제공할 뿐, 엄격한 표준이 없기 때문에 설계가 자유로워 일관성 유지가 어려울 수 있습니다.

 

 

 

REST API

정의

• REST 아키텍처 원칙을 따라 구현된 애플리케이션 프로그래밍 인터페이스(API)입니다.
• 클라이언트와 서버 간의 웹 서비스 통신을 위해 설계됩니다.
• 최근 OpenAPI(누구나 사용할 수 있도록 공개된 API: 구글 맵, 공공 데이터 등), 마이크로 서비스(하나의 큰 애플리케이션을 여러 개의 작은 애플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍처) 등을 제공하는 업체 대부분은 REST API를 제공

특징

• HTTP 메서드(GET, POST, PUT, DELETE 등)를 통해 자원에 대한 CRUD(Create, Read, Update, Delete) 작업을 수행합니다.
• URI를 통해 자원(Resource)을 지정하고, MIME 타입을 통해 자원의 표현 형식을 명시합니다.

 

 

 

RESTful

정의

• 'RESTful'은 REST 원칙을 준수하는 웹 서비스를 가리키는 용어입니다. 이는 웹 서비스가 REST 아키텍처를 기반으로 설계되고 구현됨을 의미합니다.

목적

• 이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것
• RESTful한 API를 구현하는 근본적인 목적이 성능 향상에 있는 것이 아니라 일관적인 컨벤션을 통한 API의 이해도 및 호환성을 높이는 것이 주 동기이니, 성능이 중요한 상황에서는 굳이 RESTful한 API를 구현할 필요는 없습니다.
• RESTful 웹 서비스는 플랫폼 독립적이고, 언어 독립적인 통신을 가능하게 하며, 웹 표준을 사용하여 API를 구현합니다.

RESTful 하지 못한 예시

• CRUD 기능을 모두 POST로만 처리하는 API
• route에 resource, id 외의 정보가 들어가는 경우(/students/updateName)

 

 

 

Retrofit

정의

• Retrofit은 타입 안전(type-safe) HTTP 클라이언트 라이브러리로, Java와 Android 개발에 사용됩니다.
• REST API 호출을 간소화하고, 응답 처리를 용이하게 합니다.

목적

• Retrofit은 API와의 통신을 위한 간결하고 효율적인 방법을 제공함으로써 개발자의 작업 부담을 줄이고, 네트워크 코드의 가독성 및 유지보수성을 향상시킵니다.

특징

• 선언적 구성: 인터페이스에 어노테이션을 사용하여 HTTP 요청을 정의합니다.
• 동기 및 비동기 호출 지원
• 다양한 데이터 변환기를 통한 쉬운 데이터 처리.

장단점

• + 간결한 코드로 API와의 통신을 구현할 수 있습니다.
• + 다양한 커스터마이징 옵션이 제공됩니다.
• - Java 또는 Kotlin 등 JVM 기반 언어에 한정적입니다.