[네트워크] REST API란?

REST

REST(Representational State Transfer)
WWW(World Wide Web)과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 프로그램 아키텍처의 한 형식
웹의 기존 기술 + HTTP 프로토콜 그대로 사용 -> 웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일

REST 구성 요소

자원(Resource)

• HTTP URI는 자원을 구별하는 ID
• server에 HTTP URI(Uniform Resource Identifier) 존재
  ex) http://example.com/users/123 : ID가 123인 유저를 나타내는 자원

-> client는 URI를 이용해서 자원을 지정하고 해당 자원의 상태(정보)에 대한 조작을 server에 요청

행위(Verb)

• HTTP 프로토콜은 GET, POST, PUT, DELETE와 같은 Method 제공
  ex) 클라이언트가 GET /users/123 요청
  서버가 해당 유저의 데이터를 JSON 형식으로 응답

{
  "id": 123,
  "name": "Alice",
  "email": "alice@example.com"
}

표현(Representation of Resource)

• client가 자원의 상태(정보)에 대한 조작 요청
• server는 이에 대한 적절한 응답(representation)
• REST에서 하나의 자원은 JSON, XML, TEXT, RSS등 여러 형태의 응답을 받을 수 있음 (주로 JSON, XML)

REST 특징

Uniform Interface (유니폼 인터페이스)

• URI로 지정된 자원에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일

Stateless (무상태성)

• 작업을 위한 상태정보(세션 정보나 쿠기 정보 등)를 따로 저장하고 관리하지 않음
• API 서버는 들어오는 요청만을 단순히 처리
• 서비스의 자유도가 높아지고 구현이 단순해짐

Cacheable (캐시 가능)

• 기존 웹표준인 HTTP를 그대로 사용 -> 기존 인프라를 그대로 활용 가능
• HTTP가 가진 캐싱 기능 적용 가능
• HTTP의 Last-Modified 태그나, E-Tag를 이용하면 캐싱 구현 가능함

Self-descriptiveness (자체 표현 구조)

• REST API 메시지만 보고도 이를 쉽게 이해할 수 있는 자체 표현 구조로 되어 있음

Client-Server 구조

• REST server는 API 제공, client는 사용자 인증이나 컨텍스트(세션, 로그인 정보) 등을 직접 관리하는 구조
• server와 client 간 의존성이 줄어듦

계층형 구조

• 다중 계층으로 구성될 수 있음
• 보안, 로드 밸런싱, 암호화 계층을 추가
• 구조상의 유연성, Proxy, 게이트웨이같은 네트워크 기반의 중간매체 사용

REST 장단점

장점

• 단순하고 직관적인 아키텍처
  • HTTP 프로토콜의 기본 원칙에 따라 동작
  • GET, POST, PUT, DELETE와 같은 HTTP 메서드를 사용해 리소스 관리
  • 이해하기 쉬움
• 클라이언트-서버 분리
  • 클라이언트는 서버의 리소스 요청
  • 서버는 이를 처리해 응답만 전송
• 무상태성
  • 서버가 클라이언트의 상태를 저장하지 않음
  • 확장성이 좋고 서버 부하기 줄어듦
• 캐싱 가능
  • 요청에 대한 응답을 클라이언트 측에서 캐싱하여 서버 부하를 줄일 수 있음
  • 성능 향상
• 다양한 형식 지원
  • JSON, XML, HTML 등 다양한 데이터 형식을 사용
  • 다양한 클라이언트에서 유연하게 활용할 수 있음
• 인터넷 표준 사용
  • HTTP, URI, JSON 등 이미 널리 사용되는 표준을 따름
  • 다양한 환경에서 호환성 뛰어나고, 많은 개발 도구와 라이브러리의 지원을 받음

단점

• 무상태성으로 인한 데이터 전송 부담
  • 클라이언트의 상태 정보를 매번 요청시 전송해야 함
  • 대규모 데이터 전송이 필요한 경우 네트워크 부하가 늘어날 수 있음
• 표준화 부족
  • REST는 설계 원칙만 제공하고 구체적인 구현 방식을 정의하지 않기 때문에 API 디자인에 따라 구현이 다를 수 있음
  • 일관성이 부족하거나 비효율적으로 설계된 API가 생길 수 있음
• 복잡한 트랜잭션 처리
  • REST는 각 요청이 독립적이므로 여러 작업이 연속적으로 이루어지는 트랜잭션을 처리하기 어려움
  • 상태를 유지하며 여러 단계에 걸친 작업을 수행해야 하는 경우 무상태성때문에 불편할 수 있음
• 메서드 제약
  • 복잡한 연산에는 적합하지 않을 수 있음
  • 다중 리소스 조작이나 복잡한 쿼리는 REST에서 다루기 힘듦
• 오버헤드
  • JSON, XML 등의 데이터는 바이너리 형식에 비해 크기가 크므로 데이터가 많을 경우 오버헤드 발생 가능

REST는 간결하고 직관적인 아키텍처로, 웹 서비스 개발에 적합
BUT, 상태를 유지해야 하거나 복잡한 트랜잭션이 필요한 상황에 부적합

REST API

REST API

• REST 아키텍처 스타일을 기반으로 설계된 웹 서비스 API
• REST API는 클라이언트와 서버 간의 자원을 주고 받는 방식을 정의
• HTTP 프로토콜을 사용하여 자원에 대한 CRUD(Create, Read, Update, Delete) 작업 수행

REST API 특징

• REST 기반의 시스템을 분산해 확장성과 재사용성을 높여 유지보수 및 운용을 편리하게 할 수 있음
• REST는 HTTP 표준을 기반으로 구현하므로 HTTP를 지원하는 언어(Java, C# 등)로 클라이언트, 서버 구현 가능

REST API 설계 규칙

참고 리소스 원형

• Document: 객체 인스턴스나 데이터베이스 레코드와 유사한 개념
• Collection: 서버에서 관리하는 디렉터리라는 리소스
• Store: 클라이언트에서 관리하는 리소스 저장소

중심 규칙

• URI는 정보의 자원을 표현해야 함
• 자원에 대한 행위는 HTTP Method (GET, POST, PUT, DELETE 등)으로 표현

세부 규칙

1. /는 계층 관계를 나타내는데 사용
2. URI 마지막 문자로 / 포함하지 않음
3. -는 URI의 가독성을 높이는데 사용
4. _는 URI에 사용하지 않음
5. URI 경로에는 소문자가 적합
6. 파일확장자는 URI에 포함하지 않음
   • REST API 에서는 메시지 바디 내용의 포맷을 나타내기 위한 파일 확장자를 URI 안에 포함 X
   • 대신 Accept Header 사용
     ex) GET: http://restapi.exam.com/orders/2/Accept: image/jpg
7. 리소스 간에 연관관계가 있는 경우
   • /리소스명/리소스ID/관계가 있는 다른 리소스 명
     ex) GET: /users/2/orders (일반적으로 소유 관계 표현할 때 사용)

RESTful

RESTful

• REST라는 아키텍처를 구현하는 웹 서비스를 나타내기 위해 사용되는 용어
• REST API를 제공하는 웹 서비스를 RESTful하다고 함
• REST 원리를 따르는 시스템은 RESTful 이라고 함

RESTful의 목적

• 이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것
• RESTful한 API를 구현하는 근본적인 목적은 일관적인 컨벤션을 통한 API의 이해도 및 호환성 높이기 -> 성능이 중요한 경우 굳이 RESTful한 API 구현 필요 X
• RESTful하지 못한 경우
  ex1) CRUD 기능을 모두 POST로만 처리하는 API
  ex2) route에 resource, id 외의 정보가 들어가는 경우 (/students/updateName)

참고
https://velog.io/@somday/RESTful-API-%EC%9D%B4%EB%9E%80
https://junvelee.tistory.com/107
https://hahahoho5915.tistory.com/54
🤖 Chat GPT