드디어 나도 말로만 듣던 REST API 를 공부 했다 ~~!!!
룰룰랄라룰루뿅
API
API(application programming interface) 란 응용프로그램 프로그래밍 인터페이스를 의미한다.
컴퓨터나 컴퓨터 프로그램 사이의 연결이다.
컴퓨터와 인간을 연결 시키는 사용자 인터페이스 (User interface)와 반대로 API 는 컴퓨터나 소프트웨어를 서로 연결한다.
인터페이스
두 개 이상의 시스템, 장치, 소프트웨어 등이 상호 작용 할 수 있도록 만들어진 경계나 수단을 의미한다.
하드웨어 인터페이스: 두 개 이상의 하드웨어 장치가 통신하고 상호 작용 할 수 있도록 하는 부분을 의미한다. 예를 들어 컴퓨터에 입력을 넣을 수 있는 키보드 , 컴퓨터의 출력을 할 수 있게 도와주는 모니터 등이 하드웨어 인터페이스에 속한다.사용자 인터페이스 (UI): 사용자와 시스템 간의 상호 작용을 가능하게 하는 부분을 가리킨다. 예를 들어 배달의 민족 어플리케이션을 통해 가게를 검색하고, 주문을 하는 등 서비스 를 이용 할 수 있는 어플리케이션 등이 해당 된다.프로그래밍 인터페이스: 소포트웨어 모듈이나 라이브러리 등이 다른 프로그램에서 사용 될 수 있도록 제공되는 특정한 메소드나 함수의 집합을 의미한다.소프트웨어 인터페이스: 소프트웨어 컴포넌트 간의 상호작용을 가능하게 하는 부분을 의미한다. 배달의 민족 어플리케이션이UI였다면, 가게를 검색 할 때 어플리케이션은 가게의 정보가 담긴 데이터베이스와소프트웨어 인터페이스를 통해 정보를 주고 받는다.인터페이스는 다양한 형태로 존재하지만 서로 다른 시스템 구또는 구성 요소 간의 효과적인 상호작용을 촉진 한다는 점은 동일하다.
API 는 최종 사용자가 직접 사용되도록 고안 된 것이 아니며, 소프트웨어 간 통신을 이용하여 서비스를 만들고자 하는 컴퓨터 프로그래머 가 사용 할 수 있는 도구나 서비스의 역할을 하도록 돕는다.
API 를 사용 할 때 해당 부분을 호출(call) 한다고 하고 , API 를 구성하는 호출들은 서브루틴 , 메소드 요청, 통신 엔드 포인트라고도 부른다.
이러한 규격들은 API 규격 을 통해 연결법이나 사용하는 방법을 기술하는 문서로 정리되어 있다.
API 라는 용어는 웹 API 를 의미하기도 하며, 인터넷에 의해 병합된 컴퓨터들 간 통신을 허용한다.
(물론 다른 컴퓨터간 통신이 아니라 운영체제, 하드웨어 등을 위한 API 등도 존재한다.)
정리
API는 인터페이스의 종류 중 하나이다. 인터페이스는 서로 다른 두 개 이상의 객체간의 통신을 가능하게 하는 매개체 이며API는 응용프로그램 사이 간의 통신을 가능하게 하는 컴퓨터 프로그래머를 위한 인터페이스이다.
REST API
책에서는 정의를 가볍게 훑고가기 때문에 다양한 블로그를 탐방하며 정보를 취득하던 도중 좋은 사이트 를 발견해 해당 사이트의 20분 남짓한 강의 영상을 보고 정리한다.
What is REST
REST 한 API 를 의미하는 REST API 에서 REST 하다는게 뭘까 ?
REST : REpresentational State Transfer
로 사용자가 서버에 리소스를 통해 어떤 정보를 요구하면 representational 한 정보를 서버 측에서 제공한다는 것이다.
Resource Based
Resource 는 단어 뜻대로 자원을 의미하는 것이 아닌, 정보를 요청 할 수 있는 URI 혹은 URL 을 의미한다.
URI 나 URL 은 정보나 자원을 접근 할 수 있게 도와주는 모든 것을 의미한다.
URI (Uniform Resource Identifier) , URL (Uniform Resource Locator) 라는 이름에서 알 수 있듯이 resource 를 얻기 위한 Uniform 한 식별자 혹은 주소를 의미한다.
RESTfull 한 API 는 다음과 같은 특징을 가지는 URI 를 통해 자원에 접근 할 수 있게 해야 한다.
Things vs action , Nouns vs Verbs
URI 는 어떤 행위를 하든 간 행위와 관련된 이름으로 구성되기 보다 자원과 관련된 명사들로 구성되어 있어야 한다.
예를 들어 www.clothmarket.com 이란 사이트에서 hoodie1 이란 자원에 대한 정보를 얻기 위한 URI 로 예시를 들어보자
- 잘못된 예시 :
www.clothmarket.com/gethoodie1과 같이hoodie1에 대한 정보를 얻기 위한 주소에서 액션과 관련된URI이름이 존재한다.RESTfull하기 위해서는 액션과 관련된 이름이 존재하면 안된다. - 좋은 예시 :
www.clothmarket.com/hoodie1과 같이hoodie1라는reousrce에 중점을 둔 ,Resource Based한URI를 사용해야 한다.
액션과 관련된 부분은 사용하는 메소드를 통해 관리한다.
RestAPI에서 대표적으로 사용되는HTTP에서는Resource based한URI와 액션과 관련되는GET , POST등의 메소드를 이용한다.
Separate from their representation , Identified by URIs
Resource Based 한 URI 는 안에 담긴 representation (정보) 명을 통해 구분된다.
hoodie1 을 가리키는 URI 는 www.clothmarket.com/hoodie1 였다면 hoodie2 를 가리키는 URI 는 www.clothmarket.com/hoodie2 처럼 representation 을 이용해 구분된다.
Representations
URI 를 통해 resource 에 접근하여 정보를 요청했을 때 서버는 클라이언트 측에 Representaions 들을 전달한다.
전형적으로 전달되는 Representations 들은 JSON 이나 XML 인데 주로 사용되는 타입은 JSON 이다.
예시를 통해 살펴보면
어떤 사람이 Todd 라는 사람에 대한 정보 (Resource) 를 GET 하기 위해 서버 측에 접근하여 정보를 달라고 요청했다고 해보자. (프로토콜은 HTTP 를 사용했다.)
이 때 서버는 클라이언트 측에 Todd 라는 Resource 에 대한 Representations 들을 JSON 타입으로 (혹은 XML) 전달한다.
정리
Represntation은Resource에 대한 자세한 정보들을 의미한다.Represntation은JSON , XML타입으로 전달된다.
Uniform Interface
URI , URL 에서도 등장하는 Uniform 에서 Uniform 이 뭐고 Uniform 한 Interface 라는게 뭘까 ?
사전적 의미로는 균등하다는 뜻인데 여기서도 그렇다.
어떤 환경에서도 동일한 형태의 인터페이스를 갖춰야 한다.
어떤 사이트에서 정보를 요청 할 떄 , 윈도우 환경에서 요청할 떄와 리눅스 환경에서 요청 할 때의 메소드나 URI , response (representation 을 얻기 위한) 등이 달라지면 안되고 어떤 환경에서든
동일한 인터페이스 를 제공해야 한다는 것이다.
어떤 환경에서든 동일한 인터페이스를 사용하기 위해 대표적으로 사용되는 것이 바로
- 액션을 위한
HTTP verbs, 꼭HTTP를 사용해야 하는 것은 아니지만 주로 사용한다. - 리소스 참조를 위한
URIs(resource based원칙을 지킨) - 데이터를 주고 받기 위한
HTTP response(HTTP를 이용하면 된다) 등이 있다.
Stateless
Statelss 는 RestAPI 를 제공하는 서버는 클라이언트의 state 를 기억할 필요가 없다는 것이다.
사용자가 이전에 어떤 정보를 요청하고 게시 했든지와 관한 문맥 (context) 를 기억 할 필요 없이
요청에 대해서만 서버는 수행하는 (representation 을 주고 받는) 단순한 구조여야 한다.
종종 state 를 기억하는 Rest API 등이 존재하곤 하는데, 엄밀히 말하면 stateless 가 아니기 때문에 Restfull 하다고 할 수 없다.
최대한 RestAPI 를 디자인 할 때는 stateless 할 수 있도록 노력해야 한다.
Client-Server
클라이언트와 서버는 disconneted system 을 유지해야 한다.
이는 클라이언트와 서버가 실제로 disconnected 되어 있어야 한다는 뜻보다는
연결 되어 있을 때에도 클라이언트와 서버가 직접적인 연결이 아닌, 매개체를 통해서만 접근 할 수 있도록 disconnected 되어 있어야 한다는 것을 의미한다.
이전 배달의 민족을 예시로 들었을 때
서버와 클라이언트는 어플리케이션이란 UI 를 통해 연결된다.
이 때 클라이언트가 UI 를 이용해 가게를 검색 할 때 배달의 민족 데이터베이스에 직접적으로 접근 하는 것이 아닌
UI 에서 가게 목록을 검색 할 때 , 어플리케이션이 RestAPI 를 통해 데이터 베이스와 데이터를 주고 받은 후, UI 를 통해 클라이언트 측에 representation 을 제공한다.
클라이언트와 서버의 데이터가 담긴 데이터 베이스가 직접적으로 연결 이 아닌, UI,API 를 통해 데이터를 주고 받을 때 disconnected system 이라고 한다.
정리
인터페이스를 통해 서버가 클라이언트에게 정보를 주고 받을 떄
client-server라고 한다. 매개체가 존재한다고 ~!!
Cacheable
server responses 가 Cacheable 하다는 것은 서버의 응답 (representation) 이 클라이언트에게 전달 되었을 떄 바로 제거되는 것이 아니라
어떤 기간동안 저장해두고 있다가 동일한 요청이 들어 왔을 때 서버측에서 동일하게 데이터를 가져오는 것이 아니라
저장되어 있는 (캐싱되어 있는) 정보를 전달한다는 것이다 .
이는 네트워크의 대역폭을 줄이고 응답 시간을 늘린다.
이 때 서버는 클라이언트에게 response 를 보낼 떄 헤더에 캐싱과 관련된 정보를 담고
cache control 헤더의 max age 를 통해 캐싱 할 기간을 정한다. 헤더를 통해 캐싱과 관련된 정보를 설정하고 전달한다.
implicitly
어떤 response 들은 캐싱에 대한 설정을 명시하지 안하도 암시적으로 (implicitly) 캐싱된다.
Explicitly
어떤 response 들은 캐싱에 대한 설정을 명시해야 한다.
Negotiated
클라이언트와 서버 간의 캐싱과 관련된 설정을 협상 할 수도 있다.
Layered System
계층적 구조를 가지고 있다는 것은 client-sever 에 나온 내용과 유사하다.
클라이언트가 서버에 직접적으로 연결되지 않고, 매개체들을 통해 연결되어 있었다. (클라이언트 -> UI -> API -> 데이터베이스)
이처럼 서비스는 계층적 구조를 가진 아키텍쳐를 이용하고
각 계층들은 자기와 연결된 구조들과의 통신처럼 특정 역할만을 수행하며 독립적인 구조를 갖는다.
아까 배달의 민족 예시를 들어보면
클라이언트는 서버 측에 가게 정보를 검색하는 액션을 취했지만 사실상
클라이언트 -> UI : 클라이언트가 UI 에 가게 이름을 입력하고 검색 버튼을 누름
UI -> API : UI에 입력된 정보를 가지고 API를 이용함
API -> 데이터베이스 : API를 통해 데이터베이스 측에 정보를 요청하고 정보를 받음
이와 같이 독립적이고 계층적인 구조로 되어 각 계층 별 특정 기능만을 담당한다.
독립적으로 계층적인 구조를 가지고 있으면 scalability(확장 가능성) 이 높아지며 유지보수가 용이해진다. (구조가 복잡하지 않고 단순하게 계층별 특정 기능만을 하기 때문에)
계층적 구조를 가진 RESTfull API 시스템 예시
Code on Demand
RESTfull 한 서비스는 사용자의 요청에 서버에서 코드를 가져와 실행 할 수 있는 능력을 가리킨다.
웹 어플리케이션을 가지고 예시를 들면
웹 페이지에서 자바스크립트를 이용하여 어떤 서비스들의 로직을 구현해놨다고 해보자
그럼 클라이언트는 웹 페이지에 들어가면 서버 측에서 해당 페이지의 자바스크립트 코드 실행 파일을 다운로드 받고
사용자의 액션에 맞춰 코드가 작동하며 서비스를 제공한다.
REST 의 원칙 중 Stateless 로 인해 사용자의 컨텍스트를 기억 하면 안되지만, Code on Demand 는 일시적인 코드 전송을 가능하게 함으로서 상태를 변경 할 수 있는 유연성을 제공한다.
Summary
REST API 는 위에서 말한 규격(constraint)들을 모두 지키는 Restfull 한 API 를 의미한다.
이런 규격 사항들을 지키면서 얻을 수 있는 이점들로는
client - sever관계와계층적으로 디자인된 구조를 통해scalability , simpliicity , modifiability를 높여 줄 수 있다.Uniform Interface를 통해 어떤 환경이든간 클라이언트와 서버가 일관되게 통신하여visibility를 높여준다.stateless를 통해 서버는 단순하게 동작하며 단순한 동작별 로직으로 구성되어 있어 클라이언트나 서버를 교체 할 때state의 의존성을 낮춰준다.
-state를 모두 기억해야 한다면 클라이언트가 바뀔 때 마다state를 모두 다시 암기하고,state에 따른 로직을 준비해야 하지만REST API는state와 상관없는 로직들이 존재하기 때문에 어떤 클라이언트가 오든 뚝딱뚝딱 자기가 할 일만 하면 된다.stateless덕분에 서버의 로직은 더욱 단순하고cachable로 인해 네트워크의 부하를 감소시켜reliability가 높아진다.
-reliability, 신뢰성이 올라간다는 것은 시스템이 안정적이고 예측 가능하다는 뜻이다.
출처
위키백과 : https://ko.wikipedia.org/wiki/API
REST API Tytorial : https://www.restapitutorial.com/lessons/whatisrest.html
