REST API란?

REST API는 무엇일까?

API에 대해 알아보면 대표적으로 REST API가 있다. 그렇다면 REST API는 정확히 무엇일까?

 

REST API는 "Representational State Transfer"의 약자로, 네트워크를 통해 클라이언트와 서버 간의 상호작용을 위한 규칙과 원칙을 정의한 아키텍처 스타일이다.

REST API는 HTTP 프로토콜을 기반으로 하여, 클라이언트가 특정 리소스에 접근할 수 있도록 하고, 이 리소스는 일반적으로 JSON 형식의 데이터를 통해 표현된다.

리소스는 URL을 통해 고유하게 식별되며, 클라이언트는 이 URL에 HTTP 메서드(GET, POST, PUT, DELETE 등)를 사용해 요청을 보내고, 서버는 요청에 대한 응답을 반환하는 방식으로 동작한다.

REST API의 구조

자원 (Resource)

리소스는 REST API에서 관리하고자 하는 대상이다. 사용자, 게시글, 제품 등과 같은 실체를 가리키며 리소스는 서버에 의해 고유하게 식별된다. 각 리소스는 하나의 URI(Uniform Resource Identifier)로 나타난다.

 

URI (Uniform Resource Identifier)

URI는 각 리소스를 식별하는 고유한 경로이다.

REST API에서 URI는 리소스의 위치를 나타내며 클라이언트는 이 URI를 통해 서버에 요청을 보낼 수 있다.

URI는 일관성과 명확성을 유지해야 하며 리소스를 쉽게 이해할 수 있도록 설계된다.

 

URI예시 

•  https://fabric0de.com/user  --> 사용자 전체를 의미하는 URI로 USER은 Collection 리소스
•  https://fabric0de.com/user/1  -->  특정 사용자를 나타내는 URI로 1은 Collection 리소스의 단일 리소스인 Element 리소스

URL과 URI?
URI는 인터넷 상의 자원을 식별하기 위한 모든 문자열을 말하고 URL
은 자원의 위치를 식별할 수 있는 URI의 한 형태다.
쉽게 말해 모든 URL은 URI이지만 모든 URI가 URL은 아니다.

 

HTTP 메서드 (HTTP Methods)

HTTP 메서드는 클라이언트가 서버에 요청할 때 수행할 작업을 정의한다.

REST API는 주로 아래의 HTTP 메서드를 사용하여 CRUD(Create, Read, Update, Delete) 작업을 수행한다.

• GET: 서버로부터 리소스를 조회 (Read)
• POST: 서버에 새로운 리소스를 생성 (Create)
• PUT: 서버에 존재하는 리소스를 대체하거나 수정 (Update)
• PATCH: 리소스의 일부를 수정 (Partial Update)
• DELETE: 서버에서 리소스를 삭제 (Delete)

표현 (Representation)

표현은 서버에서 클라이언트로 리소스를 전달하는 방식이다.

표현은 주로 JSON이나 XML 형식으로 이루어지며 클라이언트는 이 표현을 통해 리소스의 상태나 데이터를 받는다. 표현은 리소스의 속성, 관계 등을 포함할 수 있다.

{
  "id": 1,
  "name": "JUNG HYEON",
  "email": "junghyeonkim.dev@gmail.com"
}

 

상태 코드 (Status Codes)

HTTP 상태 코드는 클라이언트의 요청에 대한 서버의 응답 상태를 나타낸다. REST API에서 흔히 사용되는 상태 코드는 다음과 같다.

• 200 OK: 요청이 성공적으로 처리되었음을 나타냄
• 201 Created: 리소스가 성공적으로 생성되었음을 나타냄
• 204 No Content: 요청이 성공적이지만, 반환할 내용이 없음을 의미함
• 400 Bad Request: 잘못된 요청이었음을 나타냄
• 404 Not Found: 요청한 리소스를 찾을 수 없음을 나타냄
• 500 Internal Server Error: 서버에서 처리 중 오류가 발생했음을 나타냄

이 외에 상태 코드는 아래 MDN 링크를 참고하면 좋다.

HTTP 상태 코드 - HTTP | MDN

 

헤더 (Headers)

HTTP 헤더는 요청이나 응답에 대한 추가 정보를 담고 있다.

클라이언트와 서버 간에 전달되는 메타데이터로, 콘텐츠 타입(Content-Type), 인증(Authentication), 캐시 제어(Cache-Control) 등의 정보를 포함할 수 있다.

• Content-Type: application/json: 서버가 응답으로 JSON 데이터를 반환할 것을 명시
• Authorization: Bearer <token>: 클라이언트가 인증 토큰을 사용하여 요청하는 경우

REST API의 특징

무상태성 (Stateless)

각 요청은 독립적으로 처리되며 서버는 이전 요청에 대한 정보를 저장하지 않는다.

모든 요청은 필요한 모든 정보를 포함해야 한다.

 

클라이언트-서버 구조

클라이언트와 서버는 명확히 분리되어 있으며 클라이언트는 사용자 인터페이스와 요청을 관리하고 서버는 데이터 저장 및 비즈니스 로직을 처리한다.

 

캐시 가능성 (Cacheability)

HTTP 응답은 캐시될 수 있으며 클라이언트는 서버의 응답을 로컬 캐시에 저장해 동일한 요청에 대해 서버와 다시 통신하지 않고 캐시된 데이터를 사용할 수 있다.

 

계층화 시스템 (Layered System)

클라이언트와 서버 사이에 여러 중간 계층이 존재할 수 있다. 이러한 계층은 로드 밸런서, 캐시 서버 등을 포함할 수 있다.

 

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

API가 일관된 방식으로 설계되어 클라이언트는 여러 다른 API 엔드포인트에서 동일한 방식으로 상호작용할 수 있다.

이는 REST API의 핵심 원칙 중 하나이다.

REST API의 장점

확장성

REST API는 클라이언트와 서버의 독립성을 보장하기 때문에, 각각의 시스템을 독립적으로 확장할 수 있다. 이는 대규모 시스템에서도 유연한 확장이 가능함을 의미한다.

 

유연성

REST API는 다양한 데이터 포맷을 지원한다. 일반적으로는 JSON이 사용되지만, XML, YAML, 텍스트 등도 사용 가능하다.

 

캐시 처리 용이

HTTP 프로토콜의 특성을 활용해 클라이언트 측에서 응답 데이터를 캐싱할 수 있다.

이를 통해 네트워크 대역폭을 절약하고 응답 속도를 향상시킬 수 있다.

 

표준화된 인터페이스

REST API는 표준 HTTP 메서드를 사용하기 때문에 HTTP를 이해하는 누구나 쉽게 사용할 수 있다. 또한, RESTful API 설계 원칙을 따름으로써 일관된 인터페이스를 제공할 수 있다.

REST API의 단점

복잡한 요청

간단한 데이터 요청에는 적합하지만 복잡한 연산이나 트랜잭션이 필요한 경우에는 여러 번의 API 호출이 필요할 수 있다.

 

Over-fetching & Under-fetching 문제 

클라이언트가 필요한 데이터보다 더 많은 데이터를 가져오거나 반대로 필요한 데이터가 부족해 추가적인 요청이 필요한 경우가 생길 수 있다.

 

표준화의 문제 

REST API는 다양한 방식으로 구현될 수 있어 표준을 완벽히 준수하지 않는 경우 서로 다른 RESTful API 간의 호환성 문제가 발생할 수 있다.

RESTful 디자인 가이드

RESTful API는 REST 원칙을 따르는 API를 말하며 이를 설계할 때 다음 가이드를 따르는 것이 좋다.

• 명확한 리소스 기반 설계
• HTTP 메서드의 적절한 사용
• 리소스 표현의 일관성
• 쿼리 파라미터 사용