[Network] REST, RESTful API란?

📌 RESTful API란?

REST(Representational State Transfer 는 자원을 이름으로 구분하여 자원의 상태를 주고받는 소프트웨어 아키텍처 스타일이다.

REST는 웹에서 다루는 모든 데이터를 자원으로 보며, 각 자원은 고유한 URI로 식별한다. 자원을 주고받을 때, 자원 그 자체가 아니라 JSON, XML과 같은 자원의 ‘표현’을 주고받는다. 클라이언트와 서버는 HTTP 요청 및 응답을 통해 자원의 상태를 주고받는다. 서버는 클라이언트의 상태를 저장하지 않는다.

RESTful API 란 REST 원칙을 잘 지켜서 구현된 시스템 또는 API를 의미한다.

📌 REST의 구성 요소

자원(Resource)

자원은 서버가 관리하는 모든 데이터를 의미하며 각 자원은 고유한 URI로 식별된다. 클라이언트는 URI를 통해 자원을 지정하고, 서버에 해당 자원의 상태에 대한 CRUD 작업을 요청한다.

행위(Verb, HTTP Method)

자원에 대해 어떤 동작을 수행할지 표현하는 방법이다. 클라이언트가 어떤 동작을 원하는지 서버에 전달하고 서버는 해당 메서드에 맞는 동작을 수행한다.

GET : 자원 조회

POST : 자원 생성

PUT : 자원 전체 수정

PATCH : 자원 일부 수정

DELETE : 자원 삭제

표현(Representation)

자원의 실제 데이터가 클라이언트와 서버 간 주고받는 형태를 의미한다. JSON, XML, HTML 등의 형태를 가질 수 있다.

📌 REST의 특징

클라이언트-서버 구조(Client-Server Architecture)

사용자 인터페이스를 담당하는 클라이언트와 데이터를 저장 및 처리하는 서버의 역할을 명확히 분리한다. 즉, 클라이언트는 서버의 자원 URI만 알면 되고, 서버의 내부 동작을 몰라도 된다. 따라서 서버와 클라이언트는 독립적으로 개발될 수 있다.

무상태성(Stateless)

서버는 클라이언트의 상태를 저장하지 않는다. 각 요청은 독립적으로 처리되며 이전 요청의 정보를 기억하지 않는다. 이를 통해 서버 구현이 단순해지며, 확장성이 높아진다.

캐시 처리 가능(Cacheable)

서버의 응답에 해당 데이터가 캐시 가능한지 명시할 수 있다. 클라이언트 또는 프록시 서버는 캐시된 응답을 통해 동일한 요청에 대해 유연한 처리가 가능하다. 즉, 서버에 동일한 요청을 보내지 않고 응답을 받을 수 있다는 뜻이다. 이는 곧 네트워크 트래픽과 서버 부하를 줄이는 효과를 가져온다.

계층화 시스템(Layered System)

REST 시스템은 로드 밸런서, 게이트웨이 등 여러 계층으로 구성될 수 있다. 각 계층은 독립적으로 동작하며 클라이언트는 중간 계층의 존재를 알 필요가 없다.

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

REST는 일관되고 제한적인 인터페이스를 가지고 있다. 모든 자원은 URI로 식별 가능하며 HTTP Method를 통해 데이터를 조작한다. 따라서 다양한 클라이언트에서 동일한 방식으로 API를 사용할 수 있다.

📌 설계 및 구현

자원 중심 URI

• 동사가 아닌 명사로 작성한다.
  • ex) /users , posts/15
• 자원의 집합은 복수형 명사로 작성한다.
  • ex) /students
• 항상 소문자를 사용한다.
  • ex) /users (O), /Users (X)
• 여러 단어로 구성된 경우 하이픈(-)을 사용한다.
  • ex) /user-groups
• 슬래시(/)를 통해 계층 관계를 나타낸다.
  • ex) /users/3/posts (3번 사용자의 게시글)
• 마지막에 슬래시를 붙이지 않는다.
  • ex) /users (O), /users/ (X)

HTTP Method

• 목적에 맞게 메서드를 사용해야 한다.
  • ex) GET /users/1 (1번 사용자 정보 조회)
• URI에 동작이나 CRUD 함수명을 포함하면 안 된다.
  • ex) DELETE /users/1 (O), DELETE /users/delete/1 (X)

HTTP 상태 코드

• 적절한 상태 코드를 리턴하도록 해야 한다.
  • ex) 200 OK (요청 성공), 500 Unternal Server Error (서버 오류)

📌 한계 및 주의점

오버페칭(Over-fetching), 언더페칭(Under-fetching)

Over-fetching 은 클라이언트가 실제로 필요하지 않는 데이터까지 받는 현상을 말한다. REST API는 엔드포인트별로 고정된 데이터 구조를 리턴하기 때문이다. 예를 들어 사용자 정보에서 id 만 필요하나 createAt 과 같은 불필요한 데이터까지 전달될 수 있다.

Under-fetching 은 한 번의 요청으로 모든 정보를 얻지 못하여 여러 번의 추가 요청이 필요한 현상을 말한다. 예를 들어 사용자의 정보와 작성한 게시글 정보를 한 번에 받지 못하고 여러 엔드포인트를 호출해야하는 경우가 생길 수 있다.

실시간 데이터 처리 한계

REST API는 클라이언트가 필요로 할 때 서버에 요청을 보내기 때문에 실시간 데이터를 요청하는 상황에서는 비효율적이다. 이 경우, WebSocket과 같은 API가 더 적합하다.

무상태성의 한계

REST는 Stateless를 원칙으로 하므로 매 요청마다 인증 정보와 같은 필요한 데이터를 모두 포함해야 한다. 따라서 복잡한 상태 관리가 필요한 서비스의 경우 적합하지 않을 수 있다.

📌 참고

https://peonyf.tistory.com/entry/Network-REST-API

https://dev-coco.tistory.com/97