RESTful API는 뭘까

restful api에 대한 정의를 알아보자. 

평소에는 그냥 rest통신 api로 생각하고 있었다. api는 그냥 어플리케이션(프로그램) 개념이고

rest통신은 json규격 웹 데이터 전송으로 대략적으로만 이해하고 있었다.

 

그래서 RESTful api라고 하면 설명을 제대로 하지 못했다. 당연히 그게 무엇인지 정확하게 이해하고 있지 않기 때문이다.

개념정의를 정확하게 해보자. (말은 이리했지만 글쓰고 나서 다시 보니 완벽하게 이해하진 못했다. 일단 내 생각 정리를 적는다.)

 

 

www.redhat.com/ko/topics/api/what-is-a-rest-api<- 레드햇에서 만든 설명페이지. 이해하는데 도움을 준다.

ko.wikipedia.org/wiki/REST<- 위키의 설명페이지. 요약이 아주 잘 되어있다.

 

REST는 Representational State Transfer의 약자로 직역하면 '대표적인 상태 전달' 이라고 한다. 

한 문장으로 정리하자면 REST는 네트워크 아키텍처 원칙의 모음이다.  

API 개발자는 REST를 다양한 방식으로 구현할 수 있다.

 

즉, 소프트웨어 아키텍쳐에 사용되는 패턴이라고 이해했다. 이 패턴을 적용하여 소프트웨어를 설계할 수 있다.

그렇다면 해당되는 원칙은 무엇일까? 6개의 원칙(+4)을 내가 이해한 내용대로 주석을 달겠다. 이는 느슨한 정의에 가깝다.

 

1. 클라이언트, 서버 및 리소스로 구성되었으며 요청이 HTTP를 통해 관리되는 클라이언트-서버 아키텍처

-> RESTful의 요소는 클라, 서버, 리소스 3개 요소로 구성되어있으며 http 규격 통신을 통해 data 전달이 되는것

2. 스테이트리스(stateless) 클라이언트-서버 커뮤니케이션: 요청 간에 클라이언트 정보가 저장되지 않으며, 각 요청이 분리되어 있고 서로 연결되어 있지 않음

-> 링크된 페이지에 들어가면 스테이트리스의 정의가 무엇인지 나오는데, 단기적이고 서버에 과거 트렌젝션 정보를 저장하지않는, 독립적인 api를 뜻하는 것이다. 1번의 데이터 전송이 1번의 리턴으로 끝나 바로 동작이 종료되는 형식이라고 생각한다.

 

3. 클라이언트-서버 상호 작용을 간소화하는 캐시 가능 데이터

-> 해당 api를 재호출시 클라이언트단에 캐시 저장(리턴값을 임시 저장, 이는 호출 주소가 바뀌거나 시간이 지나면 새로 로드하는)을 하여 서버에 부담을 주지 않는게 가능해야한다. 

 

4. 정보가 표준 형식으로 전송되도록 하기 위한 구성 요소 간 통합 인터페이스. 여기에 필요한 것은 다음과 같습니다.

    - 요청된 리소스가 식별 가능하며 클라이언트에 전송된 표현과 분리되어야 합니다.

-> 리소스를 식별 할 수 있다.(여기서는 URL 주소인것같다.) 인풋과 아웃풋이 명확히 구분되어야 한다.

    - 수신한 표현을 통해 클라이언트가 리소스를 조작할 수 있어야 합니다(이렇게 할 수 있는 충분한 정보가 표현에 포함되어 있기 때문).

-> 이건 레드햇에서 무슨 소리를 하는지 모르겠어서. 타 블로그에서 따온다.

-> 리소스 자체를 전송하는 것이 아닌 리소스의 표현을 전송한다.예를 들어, GET http://www.example.com/v2/apple 는 사과 그 자체(리소스)가 아닌 사과를 묘사한 표현를 전송한다. 리소스 자체가 아닌 표현을 사용함으로써 서버의 코드에 얽메이지 않고 client를 구현할 수 있고, 서버의 수정에 거의 영향을 받지 않는다.(최소한 영향을 줄일 수 있다.)(출처:amazingguni.github.io/blog/2016/03/REST%EC%97%90-%EB%8C%80%ED%95%9C-%EC%9D%B4%ED%95%B4-1)

 

    - 클라이언트에 반환되는 자기 기술적(self-descriptive) 메시지에 클라이언트가 정보를 어떻게 처리해야 할지 설명하는 정보가 충분히 포함되어야 합니다.

-> 말 그대로 메시지 안에 설명이나 사용자가 이용할 수 있는만한 리턴을 보내야 한다.

    - 하이퍼미디어: 클라이언트가 리소스에 액세스한 후 하이퍼링크를 사용해 현재 수행 가능한 기타 모든 작업을 찾을 수 있어야 합니다.

-> 이것도 블로그를 참조하였다.

<!-- GET로 task들의 list를 가져오고 -->

<a href="http://example.com/v2/tasks"/>

<!-- POST로 task를 추가한다 -->

<form action="http://example.com/v2/tasks"/>

이런 식으로 href나 action으로 같은 어플리케이션이라도 액션을 제어한다는 뜻이다. 이거..맞나? 예시를 본 적이 없어서 판단하기가 힘들다.

 

5. 요청된 정보를 검색하는 데 관련된 서버(보안, 로드 밸런싱 등을 담당)의 각 유형을 클라이언트가 볼 수 없는 계층 구조로 체계화하는 계층화된 시스템.

-> 보안과 로드 밸렁싱 등을 담당하는(내부 네트워크나 서버의 자원을 관리하는)에 클라이언트 단에서 접근이 불가능하게 계층을 만들어야한다.

 

6. 코드 온디맨드(선택 사항): 요청을 받으면 서버에서 클라이언트로 실행 가능한 코드를 전송하여 클라이언트 기능을 확장할 수 있는 기능. 

-> 클라이언트는 리소스에 대한 표현을 응답으로 받고 처리해야 하는데, 어떻게 처리해야 하는지에 대한 Code를 서버가 제공하는 것을 의미한다. Html에서의 javascript가 가장 대표적인 예이다. 하지만 서버에서 제공되는 코드를 실행해야 하기 때문에 보안 문제를 야기할 수 있다. (출처: amazingguni.github.io/blog/2016/03/REST%EC%97%90-%EB%8C%80%ED%95%9C-%EC%9D%B4%ED%95%B4-1)

-> 클라 -> 서버 -> 리턴값으로 클라의 기능을 동작시킨다. 라는 내용으로 이해했다. 보안사항으로 문제를 야기할 수 있다. 

 

공부하며 느낀점은 번역의 문제와 경험의 부족함때문에 제대로된 이해를 한게 맞는지 걱정부터 앞선다.

 

또, 이걸 웹 api 개념뿐만 아니라 마이크로 서비스 어플리케이션과 연계하여 이해하고, resource적인 요소 (컬렉터, 도큐먼트 등의 개념)을 연계하여 이해해야한다.  추상적인 단계에서 restapi가 무엇인지 이해하고 특정 포맷에 따르지 않고 새로운 소프트웨어 디자인을 할 수 있어야 할 것이다.