REST API (1)

API 개발을 해보신 분들이나, 졸업 작품을 해보신 분들은 한 번쯤 들어봤을 내용이라 생각합니다.

REST API, RESTful API 등으로 불리고 있고 해당 내용은 몇 번을 강조해도 지나치지 않습니다.

 

이미 나온지는 꽤 오래되었고, 제가 처음 이에 대해 들은 건.. 16년도 쯤 같습니다.

그땐 뭐가 뭔지 잘 이해하지 못했지만, 개발 경험과 여러 자료를 지속적으로 읽어보고 찾아본 끝에 알 수 있게 되었습니다.

특히 네이버 Deview 2017에서 이응준님께서 발표하신 그런 REST API로 괜찮은가 영상은 꼭 보시라고 말씀드리고 싶습니다.

(이 글도 해당 영상의 내용을 참고하여 정리했습니다.)

 

REST가 저에게 제대로 스며들기 시작한 영상이고 계속해서 시간 날 때마다 이 영상을 보고 생각하고 공부하고 있습니다.

(많은 분들이 추천해 주시는 영상 중 하나이기도 합니다.)

 

 

 

API란 무엇일까요? API가 정확히 무엇인지 알아야 API를 REST하게 구성할 수 있겠죠.

 

API (Application Programming Interface)

응용 프로그램에서 사용할 수 있도록, 운영 체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스를 뜻한다.
주로 파일 제어, 창 제어, 화상 처리, 문자 제어 등을 위한 인터페이스를 제공한다.

(출처: wiki)

 

Interface는 우리가 잘 알고있는 그러한 인터페이스입니다. 인터페이스의 사전적 정의는 접점 인데요.

평소 인터페이스의 기능을 보면, 어떤 기능과 기능 사이 또는 기능을 사용하기 위한 접점 역할을 하니 이해가 됩니다.

 

따라서 API도 어떤 접점 역할을 하는데, 그것이 바로 위에 정의된 '운영 체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게' 그런데 응용 프로그램에서 사용할 수 있도록 접점이 되어주는 것이 API입니다.

 

쉽게 풀어서 이야기하자면 응용 프로그램에서 OS나 프로그래밍 언어의 기능을 이용하기 위한 수단으로 보시면 되겠습니다.

서버 개발시 MVC 패턴을 통해 만드는 API도 이런 역할을 하죠. (당연히 쓰이는 부분이나 기능상의 차이는 존재하지만요.)

 

 

REST API (REpresentational State Transfer API)

REST API에서 API는 이러한 서버 API와 매우 가까운 개념입니다.

API를 REST하게 구성해보자라는 것이 취지인데 정확한 개념은 아래와 같습니다.

REST(Representational State Transfer)는 월드 와이드 웹과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식이며, 컴퓨터와 인터넷 사이의 상호 운용성을 제공하기 위한 방법.

(출처: wiki, 그런 REST API로 괜찮은가)

 

 

그런데, REST란 개념이 왜 필요하게 된 것일까요?

 

웹에서는 하이퍼텍스트를 이용해 연결하여 데이터를 주고 받습니다.

표현 형식은 HTML, 식별자는 URI, 전송 방법은 HTTP(protocol)

 

예를들어 우리가 어떤 게임을 하는데 캐릭터나 빠르고 편리한 기능이 추가 될 때 일반적으로 업데이트를 통해 패치를 하죠.

또한, 업데이트가 진행됐는데 패치를 하지않으면 호환성 문제로 기존 기능을 사용하지 못하거나, 아예 접속 자체가 안될 때가 있죠.

 

웹도 마찬가지였습니다.

http 초기 버전이 시간이 갈 수록 더 나은 기능들로 바뀌면 좋을 것 같고 결국 어떤 업데이트를 필요로하게 되는데요.

이러한 업데이트를 하면 호환성 문제로인해 이미 넓게 구축된 웹이 정상 작동이 어려워 질 가능성이 있었습니다.

 

어떻게 하면, 웹과의 호환성을 깨지 않고 http를 향상시킬 수 있을까?의 해답으로 나온것이 REST입니다.

다음으로 REST를 만족하는 조건, 즉 진정한 REST가 무엇인지 알아보겠습니다.

 

REST API는 6가지 조건을 만족해야 합니다.

1. Server-Client 구조
2. Stateless
3. Cache
4. Layered System
5. Code-on-demand (optional)
6. Uniform Interface

이 중 가장 신경써야 할 부분은 Uniform Interface입니다.

왜 그런지 위에서부터 하나씩 살펴보도록 하겠습니다.

 

우선 Http만 제대로 구성해도 1 ~ 4의 조건은 충족할 수 있습니다.

Http의 개념과 어떤 성질을 가지는지 간략히 보겠습니다.

 

HTTP(HyperText Transfer Protocol)

HTTP(HyperText Transfer Protocol)는 WWW 상에서 정보를 주고받을 수 있는 프로토콜이다.
주로 HTML 문서를 주고받는 데에 쓰인다. TCP와 UDP를 사용하며, 80번 포트를 사용한다.

(출처: wiki)

 

① Server - Client 구조

문서를 주고 받는 즉, HTTP는 클라이언트와 서버사이에 이루어지는 요청/응답(request/response) 프로토콜입니다.

클라이언트에서 서버로 요청을하면, 서버에서는 요청 내용을 확인하고 그에 맞는 응답을 보내줍니다.

 

② Statless

HTTP는 연결 상태를 유지하지 않는 비연결성 프로토콜입니다.

위에서 말씀드린대로 연결한 상태를 유지한 채로 정보교환을 하는 것이 아닌 필요한 경우에 요청을하고 그 때마다 응답하는 방식입니다.

(독립적 통신)

 

③ Cache

이렇게 비연결성을 통한 요청/응답을 수행한다면, 같은 요청에도 매번 정보를 확인하고 응답받는 등 상당히 비효율적으로 동작할 것입니다.

이 문제를 해결하기 위해 HTTP에서는 Cache를 통해 응답받은 정보를 보관해 둡니다.

즉, 브라우저에 응답으로 온 HTML이나 JSON같은 데이터가 저장되고 같은 요청은 다시 보내지 않아도 Cache를 통해 사용 가능합니다.

 

④ Layered System

계층적(hierarchical) 구조가 가능해야 하며, 각 레이어에 속한 구성요소는 인접하지 않은 레이어의 구성요소를 볼 수 없어야합니다. 이와 같은 계층화 구조를 통해 각 계층의 독립적인 구성을 강조하고 있습니다.

독립적 구조는 확장을 용이하게 해주고 구성 요소의 간소화를 도와주기 때문이죠.

 

 

 

HTTP를 통해 4가지 조건 모두 충족이 되었습니다.

다음은 Code-on-demand 입니다.

 

⑤ Code-on-demand (optional)

서버에서 클라이언트가 실행시킬 수 있는 로직(e.g. javascript 코드)을 전송하여 실행할 수 있어야한다라는 뜻입니다.

 

 

이렇게 1 ~ 5의 내용은 사실상 간단하게(?) 충족시킬 수 있었습니다.

위에서 말씀드렸지만 문제는 6입니다.

 

⑥ Uniform Interface

Uniform Interface는 4가지 제약조건으로 이루어져 있습니다.

• Identification of resources
• Manipulation of resources through representations
• Self-descriptive message
• Hypermedia as the engine of application state (HATEOAS)

 

이 네가지를 모두 만족해야 Uniform Interface가 지켜지는 것인데요.

이 내용은 조금 길어질 것 같으니 다음 포스팅으로 이어가도록 하겠습니다.

 

 

잘못된 내용이나, 이해가 잘 안되는 부분은 댓글로 알려주시면 늦지않게 답변 드리겠습니다. 감사합니다.

 

 

 

 

 

참고 자료

Terms - CGI

Paper: Representational State Transfer - Roy Fielding

Deview2017 - 그런 REST API로 괜찮은가