REST API란? 백엔드 개발자가 알아야 할 개념 정리
프로젝트를 진행할 때 프론트와 백엔드의 통신에 REST API를 사용하였으나 자세히는 알지 못해서 정확히 무엇인지 알아보고자 합니다.
API란?
REST API를 설명하기에 앞서 API의 정의부터 알아보자면
API(Application Programming Interface)는 애플리케이션(소프트웨어) 간 상호 작용을 가능하게 하는 인터페이스를 의미합니다. 소프트웨어는 요청과 응답을 통해서 상호 작용을 하는데 여기서 요청과 응답의 형식을 정해놓은 규칙을 API라고 합니다.
REST API란?
REST API는 API의 형식 중에서 가장 널리 사용되는 것 중에 하나입니다.
REST API에서 REST는 Representational State Transfer의 약자로, 소프트웨어 아키텍처의 한 형식으로 즉, 자원을 이름(자원의 표현)으로 구분하여 해당 자원의 상태(정보)를 주고받는 모든 것을 의미합니다. 주로 JSON 또는 XML 형식으로 데이터를 주고받습니다.
REST는 월드 와이드 웹(WWW)과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 개발 아키텍처의 한 형태입니다.
기본적으로 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에 웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일입니다.
REST의 개념과 특징
REST는 자원(Resource) 중심의 구조(ROA, Resource Oriented Architecture)로 설계됩니다.
즉, 웹의 모든 자원(Resource)에 고유한 ID인 HTTP URI를 부여하고 이를 HTTP 메서드(POST, GET, PUT, DELETE)를 활용하여 처리하는 방식입니다.
REST API는 HTTP 메서드 (POST, GET, PUT, DELETE)를 사용하여 CRUD 작업을 수행하는데 CRUD(Create, Read, Update, Delete)는 애플리케이션에서 데이터(EX 사용자 정보, 게시글 등)를 관리하는 기본적인 작업 방식입니다.
https://youtu.be/fB3MB8TXNXM?si=ASLyl1uKBQJ3qCi3
REST의 주요 특징
- 클라이언트-서버(Client-Server) 구조
- 클라이언트(프론트엔드)와 서버(백엔드)가 분리되어 있어야 합니다.
- 서버는 데이터 처리와 저장을 담당하고 클라이언트는 사용자에게 데이터를 보여줍니다.
- 즉 프론트엔드와 백엔드가 독립적으로 개발될 수 있어야합니다.
- 무상태성(Stateless)
- 각 요청 간의 상태를 저장하지 않으며, 요청마다 필요한 정보를 포함해야 합니다.
- 즉 서버는 클라이언트의 이전 요청 정보를 기억할 필요가 없습니다.
- 캐시 가능(Cacheable)
- HTTP의 캐싱 기능을 활용하여 성능을 향상시킬 수 있습니다.
- 자주 사용하는 데이터는 캐시에 저장하여 속도를 높이고 서버 부하를 줄입니다.
- 계층화 구조(Layered System)
- REST API는 여러 계층(Layer)으로 구성될 수 있습니다.
- 보안, 로드 밸런싱, 프록시 등 다양한 계층을 추가할 수 있습니다.
- 클라이언트는 직접 데이터베이스와 통신하지 않고 중간 서버를 통해 요청을 처리합니다.
- 인터페이스 일관성(Uniform Interface)
- HTTP 표준을 따르는 일관된 방식으로 API를 설계해야 합니다.
- 즉, URL 형식을 통일하여 개발자가 쉽게 이해하고 사용할 수 있도록 해야합니다.
- Code on Demand (선택적)
- 클라이언트가 필요할 경우 서버로부터 실행 가능한 코드를 받을 수 있습니다.
- 이 기능은 필수는 아니지만, 특정 서비스에서는 활용될 수 있습니다.
REST API의 구성 요소
REST API는 자원(Resource), 행위(Verb), 표현(Representation) 세 가지 요소로 구성됩니다.
1. 자원 (Resource)
REST에서는 모든 데이터를 자원(Resource)으로 표현합니다.
- 예: 사용자(User), 게시글(Post), 상품(Product) 등
이러한 자원은 고유한 식별자(URI, Uniform Resource Identifier)를 가집니다.
- GET /users/1 → 1번 사용자 정보 조회
2. 행위
자원에 대한 작업을 수행할 때는 HTTP 메서드를 사용합니다.
| GET | 자원 조회 (Read) | GET /users/1 (1번 사용자 조회) |
| POST | 자원 생성 (Create) | POST /users (새 사용자 등록) |
| PUT | 자원 전체 수정 (Update) | PUT /users/1 (1번 사용자 수정) |
| PATCH | 자원 부분 수정 (Partial Update) | PATCH /users/1 (이름만 수정) |
| DELETE | 자원 삭제 (Delete) | DELETE /users/1 (1번 사용자 삭제) |
3. 표현 (Representation)
클라이언트와 서버가 데이터를 주고받을 때 JSON, XML 등의 형태로 표현(Representation) 됩니다.
예를 들어, GET /users/1 요청 시 서버는 JSON 데이터를 응답할 수 있습니다.
RESTful API 설계 원칙
RESTful API를 설계할 때 다음 원칙을 따르는 것이 중요합니다.
1) URI는 자원을 나타내야 한다. (명사 사용)
- GET /users → 모든 사용자 조회
- GET /users/1 → 특정 사용자 조회
- GET /getUser?id=1 → 동사 사용 X
2) 행위(동작)는 HTTP 메서드를 활용한다.
- POST /users → 새 사용자 추가
- GET /createUser → URL에 동사 사용 X
3) 계층적 구조를 활용한다.
- GET /users/1/orders → 1번 사용자의 주문 목록 조회
- GET /getUserOrders?userId=1 → 동사 사용 X
HTTP 상태 코드 (HTTP Status Codes) 정리
HTTP 상태 코드는 클라이언트 요청에 대한 서버의 응답 상태를 나타내는 숫자 코드입니다. REST API에서 클라이언트가 요청을 보낼 때, 서버는 적절한 상태 코드를 응답과 함께 반환합니다. 보통 요청이 성공적으로 수행되었을 때는 200 ok라는 응답을 보내는데 요청에 따른 HTTP 상태 코드에는 어떤 것들이 있는지 간단하게 살펴보겠습니다.
2XX - 성공적인 요청의 응답
4XX - 클라이언트 요청의 오류
- URL 문제이거나 권한 외의 요청
- 접근 권한이 없음
5XX - 서버의 오류
- 서버에서 예상치 못한 오류
- 서버가 과부하 상태이거나 유지보수 중
'백엔드 스터디' 카테고리의 다른 글
| 스프링 OAuth2 로그인 구현하기 2 (4) | 2025.08.09 |
|---|---|
| 스프링 OAuth2 로그인 구현하기 1 (2) | 2025.08.04 |
| 디스패처 서블릿이란? (0) | 2025.04.02 |
| 서블릿이란? (0) | 2025.04.01 |
| 엔티티(Entity) 개념과 설계, 연관관계 (0) | 2025.03.26 |
