REST API 란?
흔히 웹 개발자라면 REST API , REST ful 이란 말을 들어보셨을 겁니다.
이 REST API는 명확하게 무엇을 의미할까요?
REST를 한번 뜯어봅시다.
REST : Representational State Transfer API의 뜻으로 2000년대 웹의 장점을 최대한 활용할 수 있는 아키텍처입니다.
여기서 API는 Application Programming Interface로 애플리케이션에서 프로그래밍을 구축하고 통합하는 정의 및 프로토콜입니다. 흔히 API를 직접 프로젝트에서 활용할 때는 개발자(생산자)와 소비자(클라이언트)가 필요로 하는 호출(Request)과 응답(Response)을 구축합니다. 컴퓨터나 시스템에 사용자가 원하는 정보를 호출 및 응답받을 수 있도록 도와주는 조정자라고 생각하면 좋을 것 같습니다.
이어서 REST API를 설명하기 전 URI와 URL의 개념을 한번 짚고 넘어갑시다.
URL, URI 많이 들어봤는데 실제로 명확하게 어떤 차이점이 있을까요?
URN과 URL은 사실 URI에 포함되어있습니다.
위 사진을 보면 조금은 감이 오실까요?
위치는 고정적이며 식별자라고는 말할 수 없기 때문에 URL이며 URL 속 식별자를 이용해 특정 데이터를 지정할 수 있습니다.
이처럼 REST API를 이용할 때 URI를 통해 특정 데이터를 호출하고 응답받을 수 있습니다.
REST API 구성요소
REST API는 3가지의 구성요소가 있습니다.
- 자원(RESOURCE) - URI
- 행위(Verb) - HTTP method
- 표현(Representations) - Representation of Resource
여기서 자원은 위에서 설명드린 URI개념으로 서버에 특정 자원을 Identifier로 구별하고 호출할 수 있어야 합니다.
행위(Verb)는 기본적인 HTTP 요청 Method로 Get, Put, Delete, Post, Patch를 통해 서버에 요청을 보낼 수 있어야 합니다. 우리는 흔히 CRUD(Create, Read, Update, Delete 기능을 구현하는 것과 매칭 된다고 보시면 됩니다.) 기능을 구현하고 이를 앞에 메서드에 맞게 구현합니다.
표현은 위 자원을 나타내는데 이 자원을 주고받기 위한 형식이 일반적으로 JSON, XML 형식이라는 것입니다.
그래서 이 구성요소로 어떻게 한다는 건데~라고 생각할 수 있는데
위 구성요소를 활용해 REST API라고 불리는 아키텍처 규칙에 맞게 구현해야 합니다.
이 설계 규칙을 모두 적절하게 잘 지켰을 경우 우리는 RESTful API라고 말할 수 있습니다.
이 REST API의 설계 규칙은 다음과 같습니다.
1) Uniform (유니폼 인터페이스) - 일반성의 원칙을 적용하고 아키텍처를 단순화하고 상호 작용의 가시성을 향상할 수 있다. 즉 리소스(자원)를 간결하고 명확하게 그리고 고유한 표현을 통해 식별할 수 있어야 합니다 ( URI를 조금 더 명확하게 네이밍하고 이용해야 합니다.)
2) Stateless (무상 태성) - 서버는 작업에 따른 상태 데이터를 따로 저장하지 않습니다 그렇기에 구현이 단순합니다. 또 요청 응답 간의 데이터 역시나 저장하지 않으며 사용자에 대한 세션 상태는 완전히 유지해야 합니다.
3) Cacheable (캐시 가능) - REST API는 HTTP의 표준 형식을 이용하기 때문에 캐싱 기능이 존재합니다. 그중에서도 응답에 따라 캐싱 가능과 불가능으로 레이블을 분리하고 캐싱이 가능할 경우 일정 기간 동안 사용자에게 해당 응답 데이터를 재이용할 수 있는 권한을 부여할 수 있습니다. 여기서 사용되는 캐싱 기능 역시 HTTP에 존재하는 캐싱 기능입니다.
4) Self-descriptiveness (자체 표현 구조) - 위 리소스를 특정 고유 표현으로 표현했기 때문에 REST API의 메시지 만으로 어떤 의미에 요청인지를 인지할 수 있는 구조가 되어야 합니다.
5) Client - Server 구조 - 클라이언트와 서버를 명확하게 나누어 확장성을 개선해야 합니다. 클라이언트와 서버가 진화(? 업데이트할 동안) 이 클라이언트 - 서버 간의 인터페이스가 가 깨지지 않도록 합니다.
6) 계층형 구조 - 계층형 구조는 말 그대로 우리가 URI를 참조할 때 ( / ) 표현으로 리소스의 계층을 타고 갈 수 있으며 마지막에는 슬래쉬( / )를 포함하지 않아야 합니다. 또 이 API사이에 보안, 로드밸런싱, 암호화 등의 계층을 추가해 보안성을 강화하거나 Proxy, Gateway 등을 추가해 네트워크의 중간 매체를 사용할 수 있습니다.
위 6가지 규칙 중 가장 중요한 것만 기억하자면
URI는 고유명사로 데이터를 명확하게 의미할 수 있어야 하며, 해당 데이터를 활용한 행동은 꼭 HTTP method를 이용해야 한다는 걸 기억하면 좋겠습니다.
그 밖에도 주의할 점으로는
( _ ) 표시보다는 ( - ) 하이픈을 사용해야 하고, 파일의 확장자(. jpg )등을 표시하지 않아야 하며, 소문자만을 사용해야 합니다
저도 역시나 프로젝트를 진행할 때 REST API 아키텍처를 지향하며 설계하고 구성했지만 결과적으로 로컬의 일부 리소스를 끌어다 쓰는 방식의 프로젝트를 종종 사용하곤 했습니다. (동영상, 이미지와 같이 데이터베이스에 담기 껄끄러운 데이터들..) 이럴 때마다 REST API의 설계 규칙에 위배되었다는 것을 오늘 개념을 정리해보며 다시 한번 느끼는 시간이 되었다고 생각합니다.
Reference
'지식 창고' 카테고리의 다른 글
| MSA란 무엇일까? (0) | 2023.01.10 |
|---|---|
| HLS protocol 이란 무엇일까? (2) | 2022.09.11 |
| 프레임워크랑 라이브러리는 뭐가 다를까?? (0) | 2022.09.03 |