REST, RESTful API 알아보기

Yejin Yang·2022년 11월 9일

REST Restful

[TIL]

목록 보기

62/67

REST 란?

REST(Representational State Transfer)는 네트워크 리소스를 정의하고 처리하는 방법을 설명하는 일련의 원칙을 기반으로 하는 아키텍처 스타일이다.

월드 와이드 웹과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식
HTTP의 주요 저자 중 한 사람인 로이 필딩(Roy Fielding)의 2000년 박사학위 논문에서 소개해서 널리 퍼짐

API 란?

API(application programming interface)는 컴퓨터나 컴퓨터 프로그램 사이의 연결이다. 일종의 소프트웨어 인터페이스이며 다른 종류의 소프트웨어에 서비스를 제공한다.

인터페이스는 두 애플리케이션 간의 서비스 계약이라고 할 수 있다. 이 계약은 요청과 응답을 사용하여 두 애플리케이션이 서로 통신하는 방법을 정의한다.
API 아키텍처는 일반적으로 클라이언트와 서버 측면에서 설명된다. 요청을 보내는 애플리케이션을 클라이언트라고 하고 응답을 보내는 애플리케이션을 서버라고 한다.
예) 날씨 앱: 기상청의 날씨 데이터베이스는 서버이고 모바일 앱은 클라이언트이다.

RESTful API

REST API 오늘날 웹에서 볼 수 있는 가장 많이 사용되고 유연한 API이다.
REST는 효율적, 안정적이며 확장가능한 분산시스템을 가져올 수 있는 소프트웨어 아키텍처 디자인 제약의 모음을 나타낸다. 그리고 그 제약들을 준수했을 때 그 시스템은 RESTful하다고 일컬어진다.

RESTful API의 아키텍처 제약 조건

다음 제한 조건을 준수하는 한 개별 컴포넌트는 자유롭게 구현할 수 있다.

Uniform Interface(인터페이스 일관성)
1) REST API와 Non-REST API를 구분하는 핵심 제약 조건
2)기기나 애플리케이션 유형(웹사이트, 모바일 앱)에 관계없이 주어진 서버와 상호 작용하는 균일한 방법이 있어야 한다.

Stateless(무상태)
1) 요청을 처리하는 데 필요한 상태가 요청 자체에 포함되어 있고 서버가 세션과 관련된 어떤 것도 저장하지 않음을 의미
2) REST에서 클라이언트는 쿼리 매개변수, 헤더 또는 URI의 일부로 요청을 수행하기 위해 서버에 대한 모든 정보를 포함해야 한다.
3) Stateless는 서버가 해당 세션 상태를 유지, 업데이트 또는 통신할 필요가 없기 때문에 가용성을 높일 수 있다.
4) 클라이언트가 서버에 너무 많은 데이터를 보내야 하므로 네트워크 최적화 범위가 줄어들고 더 많은 대역폭이 필요하다는 단점이 있다.

Cacheable(캐시 처리 가능)
1) 모든 응답에는 응답이 캐시 가능한지 여부와 클라이언트 측에서 응답을 캐시할 수 있는 기간이 포함되어야 한다.
2) 클라이언트는 후속 요청에 대해 캐시에서 데이터를 반환하며 서버에 요청을 다시 보낼 필요가 없다.
3) 잘 관리되는 캐싱은 일부 클라이언트-서버 상호 작용을 부분적으로 또는 완전히 제거하여 가용성과 성능을 더욱 향상시킨다.
4) 그러나 때때로 사용자가 오래된 데이터를 수신할 가능성이 있다.
Layered System(계층화된 시스템)
1) 애플리케이션 아키텍처는 여러 계층으로 구성되어야 한다.
2) 클라이언트는 보통 대상 서버에 직접 연결되었는지, 또는 중간 서버를 통해 연결되었는지를 알 수 없다. 클라이언트와 최종 서버 사이에 많은 중간 서버가 있을 수 있다.
3) 중간 서버는 로드 밸런싱을 활성화하고 공유 캐시를 제공하여 시스템 가용성을 향상시킬 수 있다.
Code on demand (optional)
1) 선택적 기능, 이에 따르면 서버도 클라이언트에 실행 가능한 코드를 제공할 수 있다.
2) Java 애플릿과 같은 컴파일된 구성 요소 및 JavaScript와 같은 클라이언트측 스크립트 제공을 통해 서버가 클라이언트가 실행시킬 수 있는 로직을 전송하여 기능을 확장시킬 수 있다.
클라이언트/서버 구조
1) 클라이언트는 리소스를 요청하고 각 서버의 내부에 남아 있는 데이터 저장소 같은 비즈니스 로직에 대해 아무것도 알 필요가 없다.
2) 서버는 리소스를 보유하고 프론트엔드 UI에 대해 아무것도 알 필요가 없다.
3) 아키텍처를 단순화시키고 작은 단위로 분리(decouple)함으로써 클라이언트-서버의 각 파트가 독립적으로 개선될 수 있도록 해준다

REST API 규칙

REST API endpoints를 만들 때 염두에 두어야 하는 특정 규칙

REST는 동작 또는 동사 기반 대신 리소스 또는 명사를 기반으로 한다.
REST API의 URI는 항상 명사로 끝나야 한다.
좋은 예: /api/users
나쁜 예: /api?type=users
HTTP 동사는 작업을 식별하는 데 사용된다.
GET, PUT, POST, DELETE, GET, PATCH 등
웹 애플리케이션은 사용자와 같은 리소스로 구성된 다음 GET, PUT, POST, DELETE와 같은 HTTP 동사를 사용하여 해당 리소스를 수정해야 한다.
개발자로서 사용된 엔드포인트와 HTTP 메서드를 보는 것만으로 수행해야 하는 작업이 무엇인지 명확해야 한다.