최근에 DRF를 활용하여 프로젝트를 많이 진행하다보니 REST API에 대한 개념의 필요성도 느끼게 돼서 간략하게 정리해보고자 한다.
최근에 유튜브 알고리즘에 이끌려 관련 영상을 본 적 있었는데 정말 쉽게 가르쳐주셨었다. REST API가 뭔지 아예 모르겠다면 이 영상부터 보는 것을 추천한다.
REST API에 대해서는 아마존 공식문서-API, 아마존 공식문서-REST API를 포함한 여러 IT기업들의 공식문서들과 해외 문서들도 많다. 읽어보니 맥락은 모두 비슷비슷했다.
이 글은 참고해서 아마존 공식문서와 IBM 공식문서를 주로 참고해서 정리해보려고 한다.
1. API
1-1. API란?
우선 REST API를 알기 전에 API가 뭔지에 대해서 알 필요가 있다고 생각한다.
API
API는Application Programming Interface의 줄임말입니다.
API는 정의 및 프로토콜 집합을 사용하여 두 소프트웨어 구성 요소가 서로 통신할 수 있게 하는 메커니즘입니다.
-AWS공식문서
위의 설명과 함께 아래와 같은 예시를 들고 있다.
예를 들어, 기상청의 소프트웨어 시스템에는 일일 기상 데이터가 들어 있습니다. 휴대폰의 날씨 앱은
API를 통해 이 시스템과 "대화"하고 휴대폰에 매일 최신 날씨 정보를 표시합니다.
-AWS공식문서
여기까지의 의미를 확인했을 때 두 개의 소프트웨어 혹은 두 개의 대상이 통신하는 형식이라고 생각이 된다.
1-2. API의 의미
API는 Application programming Interface의 줄임말이라고 위에서 확인했었는데 이 단어들의 의미에 대해서 살펴보자.
Application: 고유한 기능을 가진 모든 소프트웨어를 나타냅니다.
Interface: 두 애플리케이션 간의 서비스 계약이라고 할 수 있습니다. 이 계약은 요청과 응답을 사용하여 두 애플리케이션이 서로 통신하는 방법을 정의합니다.
-AWS공식문서
한마디로 API는 소프트웨어들 간의 연결을 도와주는 일종의 Interface라고 생각할 수 있을 것이다.
우리에게 익숙한 UI와 비교하면 API의 의미가 더 와닿을 것이라고 생각한다.
UI: 사용자와 컴퓨터의 연결
API: 컴퓨터나 소프트웨어들의 연결
1-3 API의 동작원리
대충 어떤 느낌인지는 알겠으나 아직은 모호한 부분이 많다. 다음 글을 읽어보자.
API 아키텍처는 일반적으로
클라이언트와서버측면에서 설명됩니다.
요청을 보내는 애플리케이션을 클라이언트라고 하고 응답을 보내는 애플리케이션을 서버라고 합니다.
-AWS공식문서
이제 Application의 대상이 Client와 Server로 구체화되었다.
API는 4가지 방법으로 동작할 수 있으며 다음과 같다.
API 아키텍처
SOAP API
이 API는 단순 객체 접근 프로토콜을 사용합니다. 클라이언트와 서버는 XML을 사용하여 메시지를 교환합니다. 과거에 더 많이 사용되었으며 유연성이 떨어지는 API입니다.
RPC API
이 API를 원격 프로시저 호출이라고 합니다. 클라이언트가 서버에서 함수나 프로시저를 완료하면 서버가 출력을 클라이언트로 다시 전송합니다.
Websocket API
Websocket API는 JSON 객체를 사용하여 데이터를 전달하는 또 다른 최신 웹 API 개발입니다. WebSocket API는 클라이언트 앱과 서버 간의 양방향 통신을 지원합니다. 서버가 연결된 클라이언트에 콜백 메시지를 전송할 수 있어 REST API보다 효율적입니다.
REST API
오늘날 웹에서 볼 수 있는 가장 많이 사용되고 유연한 API입니다. 클라이언트가 서버에 요청을 데이터로 전송합니다. 서버가 이 클라이언트 입력을 사용하여 내부 함수를 시작하고 출력 데이터를 다시 클라이언트에 반환합니다.
-AWS공식문서
아직까진 이걸 다 알 필요는 없지만 간혹가다가 IT관련 영상을 볼 때 이따금씩 들렸던 것 같아 일단 다 적어보았다.
맨 밑에 오늘 우리가 자세히 알아볼 REST API도 보인다.
여기까지 읽었다면
"오.. 그니까 API는 웹 환경에서 서버와 클라이언트가 통신하는 인터페이스라는거네??"
라고 생각할 수 있는데 그렇게 생각하면 안된다.
1-4. 웹 API
아래의 글을 살펴보자.
웹 API또는웹 서비스 API는웹 서버와웹 브라우저간의 애플리케이션 처리 인터페이스입니다. 모든웹 서비스는API이지만 모든API가웹 서비스는 아닙니다.
REST API는 위에서 설명한 표준 아키텍처 스타일을 사용하는 특수한 유형의
웹 API입니다.
-AWS공식문서
즉 모든 API가 웹서비스에서 사용되는 것은 아니라는 것이다.
종합하자면 다음과 같다.
API는 서버와 클라이언트가 통신할 수 있도록 하는 인터페이스를 의미하며 그 중REST API는 특수한 유형의웹 API이다.
2. REST API
지금까지의 설명을 통해 REST API가 웹 API라는 것을 알 수 있었다. 이젠 REST API에 대해서 알아보자.
2-1. REST API란?
REST API에 대한 설명을 찾아보면 다음과 같다.
REST API는REST(REpresentational State Transfer)아키텍처 스타일의 디자인 원칙을 준수하는 API입니다.
-IBM공식문서
매우 당연한 말이었다. 아무래도 바로 REST가 무엇인지에 대해서 살펴보는 것이 좋을 것 같다.
2-2. REST란?
REST란 자원을 자원의 표현으로 구분하여 해당 자원의 상태를 주고 받는 모든 것을 의미한다. 즉, 자원의 표현에 의한 상태 전달을 의미한다.
자원: 해당 소프트웨어가 관리하는 모든 것,Resource
ex) 문서, 그림같은 데이터 혹은 해당 소프트웨어 자체 등
자원의 표현: 그 자원을 표현하기 위한이름
ex) DB의 학생 정보가 자원일 때, "students"를 자원의 표현으로 정한다.
상태 전달: 데이터가 요청되어지는 시점에서 자원의 상태, 즉정보를 전달한다.
쉽게 말해서, 자원을 이름으로 구분하여 접근하고 그를 통해 정보를 주고 받는 것을 의미한다.
아직은 조금 추상적일 수 있는데 구체적으로 REST에 대해 구체적으로 정의해보자.
REST는 HTTP URI를 통해 자원을 명시하고, HTTP Method를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것을 의미한다.
HTTP URI: 특정 리소스를 식별하는 통합 자원 식별자,
Uniform Resource Identifier를 의미한다.
HTTP Method:클라이언트가웹 서버에게 사용자 요청의 목적이나 종류를 알리는 수단이다. 각 요청에 대한 자세한 설명은 이 글을 참고하자.
결국 위의 설명을 풀어서 설명하면 다음과 같을 것이다.
REST란?
- 소프트웨어의 모든
자원에 고유한이름인HTTP URI를 부여하고 이를 주소처럼 사용한다.- 그를 통해 해당
자원에 접근하여CRUD operation을 수행한다.
2-3. REST의 구성요소
위의 내용을 통해서 우리는 REST의 구성요소가 다음의 3가지라는 것을 알 수 있다.
1. 자원(Resource): URI
- 모든
자원에 고유한 ID가 존재하고, 이 자원은Server에 존재한다.자원을 구별하는 ID는 ‘/groups/:group_id’와 같은HTTP URI다.Client는URI를 이용해서 자원을 지정하고 해당 자원의 상태(정보)에 대한 조작을Server에 요청한다.2. 행위(Verb): HTTP Method
- HTTP 프로토콜의 Method를 사용한다.
- HTTP 프로토콜은 GET, POST, PUT, DELETE 와 같은 메서드를 제공한다.
3. 표현(Representation of Resource)
Client가 자원의 상태(정보)에 대한 조작을요청하면Server는 이에 적절한응답(Representation)을 보낸다.REST에서 하나의자원은 JSON, XML, TEXT, RSS 등 여러 형태의Representation으로 나타내어 질 수 있다.- JSON 혹은 XML를 통해 데이터를 주고 받는 것이 일반적이다
출처 : https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html
2-4. REST의 디자인 원칙 6가지
우리가 REST API로 설계를 하려면 다음의 6가지 원칙을 따라야 한다.
1. 인터페이스 일관성(Uniform Interface)
Uniform Interface는 URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하며 특정 언어에 종속되지 않는다.
2. 무상태성(Stateless)
REST는 무상태성 성격을 갖는다. 다시 말해 작업을 위한 상태정보를 따로 저장하고 관리하지 않는다는 것이다. 세션 정보나 쿠키정보를 별도로 저장하고 관리하지 않기 때문에 API 서버는 들어오는 요청만을 단순히 처리하면 된다. 따라서 서비스의 자유도가 높아지고 서버에서 불필요한 정보를 관리하지 않음으로써 구현이 단순해집니다.
3. 캐시 처리 가능(Cacheable)
REST의 가장 큰 특징 중 하나는 HTTP라는 기존 웹표준을 그대로 사용하기 때문에, 웹에서 사용하는 기존 인프라를 그대로 활용가능하다는 것이다. 따라서 HTTP가 가진 캐싱 기능을 적용할 수 있다. HTTP 프로토콜 표준에서 사용하는 Last-Modified태그나 E-Tag를 이용하면 캐싱 구현이 가능하다.
4. Server - Client 구조
REST 서버는 API 제공, 클라이언트는 사용자 인증이나 컨텍스트(세션, 로그인 정보)등을 직접 관리하는 구조로 각각의 역할이 확실히 구분되기 때문에 클라이언트와 서버에서 개발해야 할 내용이 명확해지고 서로간 의존성이 줄어들게 된다.
5. 계층형 구조(Layered System)
REST 서버는 다중 계층으로 구성될 수 있으며 보안, 로드 밸런싱, 암호화 계층을 추가해 구조상의 유연성을 둘 수 있고 PROXY, 게이트웨이 같은 네트워크 기반의 중간매체를 사용할 수 있게 한다.
6. Code-On-Demand(optional)
REST API는 일반적으로 정적 리소스를 전송하지만, 특정한 경우에는 응답에 실행 코드(스크립트)를 포함할 수도 있다. 이러한 경우에, 코드는 요청 시에만 실행되어야 한다.
2-5 REST API 설계 규칙
REST의 정의에 따라 우리는
1. URI는 자원을 표현하는데 사용되어야 하며
2. 자원에 대한 행위는 HTTP Method로 표현되어야 한다.
만약 다음과 같은 URI가 있다고 하자.
/lists/delete/1우선 URI에 http의 메소드에 관련된 내용 혹은 동작에 관한 내용이 들어가면 안된다.
따라서 우리는 다음과 같이 변경할 수 있다.
DELETE /lists/1위와 같이 /lists/1이라는 주소로 삭제요청을 보낸다고 접근하는 것이 맞다. HTTP Method에 대해서는 이 글을 참고하자.
이 외에 다른 규칙들이 있는데 API설계시 참고하면 좋을 것이다.
URI설계 규칙
1.슬래시 구분자(/)는 계층 관계를 나타내는 데 사용
2. URI 마지막 문자로 슬래시(/)를 포함하지 않는다.
3. 하이픈(-)은 URI 가독성을 높이는데 사용
4. 밑줄(_)은 URI에 사용하지 않는다.
5. URI 경로에는 소문자가 적합하다.
6. 파일 확장자는 URI에 포함시키지 않는다.
7. 관계가 있는 리소스는 다음과 같이 사용한다.
/리소스명/리소스 ID/관계가 있는 다른 리소드ex) lists/3/image
-NHN공식사이트
추가적으로 Collection과 Document에 대한 설명도 있는데 이 부분은 필요할 때 찾아봐도 괜찮을 듯 하다.
3. 총정리
-
API는 서버와 클라이언트가 통신할 수 있도록 하는 인터페이스를 의미하며 그 중REST API는 특수한 유형의웹 API이다. -
REST API에서 클라이언트는URI를 통해서 서버의자원에 접근하고HTTP method를 통해서CRUD Operation을 한다. -
URI는 자원의 정보에 대한 내용만 기입되어 있어야 하며 모든 자원에는고유의 ID가 주어진다.
4. 더 알아보기
4-1. "Representational"의 의미
REST에 대한 설명을 찾아보면 다음과 같은 설명을 제일 먼저 찾을 수 있을 것이다.
REST(REpresentational State Transfer)는 월드 와이드 웹과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식이다.
-위키백과
굉장히 와닿지 않는 설명이다. REpresentational State Transfer을 검색하면 "웹 표현 상태 변경"이라는 정도로 찾아볼 수 있었는데 그대로 받아들이기엔 어색하다.
결정적으로 Representational이라는 단어가 와닿지 않았다. 열심히 구글링을 해본 결과 가장 괜찮은 설명을 찾을 수 있었다.
Representation: 어떤 리소스의 특정 시점의 상태를 반영하고 있는 정보
그렇기 때문에 Representation이 서버가 클라이언트에게 전달하는 응답으로 생각될 수 있는 것이라고 생각한다. 이 때의 응답이 바로 클라이언트가 URI를 통해 서버에 접근했을 때 얻어지는 Resource의 상태가 될 것이다.
4-2. 아키텍처 관점의 REST
우선 REST라는 소프트웨어 아키텍처 자체가 네트워크 기반의 여러 아키텍처가 복합적으로 합쳐짐으로써 정의되는 아키텍처 스타일이다.
REST의 창시자인 로이 필딩의 논문에서 다음과 같은 정의를 찾아볼 수 있다.
A software architecture is defined by a configuration of architectural elements--components, connectors, and data--constrained in their relationships in order to achieve a desired set of architectural properties.
-Architectural Styles and the Design of Network-based Software Architectures
즉, REST라는 아키텍처를 사용하기 위해서 우리는 제약조건을 지켜야 한다. 그렇기 때문에
2-4에서의 디자인 원칙이 정해진 것이다.
5. 후기
이 개념을 정리하기 위해서 이틀을 모두 쏟아부었었다. 사실 우리가 프레임워크를 써서 개발을 하는 측면에 있어서는 2-5번 REST API설계규칙, 그리고 3번 총정리의 내용만 알고있어도 크게 지장은 없을 것이다.
API에 관한 내용을 정리할 때는 사실 아마존 공식문서만 참고했다고 봐도 무방할 정도로 내용이 잘 정리되어 있었다.
하지만 REST에 이르러서는 오히려 다 비슷한 말들만 들어있는 문서들이 너무 많았고 의미가 잘못되거나 명확하지 않은 문서들도 여럿 존재했다.
특히 "REpresentational State Transfer"라는 풀네임이 의미하는 것이 무엇인지, 그리고 소프트웨어 아키텍처는 무엇인지 알아보는데 시간을 많이 할애했던 것 같다. 이 부분에 대해서는 아직 완벽하게 이해했다고는 말은 못하나 대략적으로 이해한 부분에 대해서는 더 알아보기에 추가하였다.
글을 작성하고 보니 간략하게 정리하겠다는 목표와 달리 내용이 너무 많고 구체적이며 특히 같은 맥락이 반복되는 부분이 너무 많아졌다. 하지만 어떻게 보면 나 스스로 REST API에 대해서 이해하는 과정이 글에서 나타난 것이기 때문에 만족한다.
나중에 시간이 생기면 논문도 한번 읽어봐야겠다.
