들어가면서
개발을 하다보면 API를 찍어낸다. API를 쓰면 된다. 등 대화가 API로 시작해서 API로 끝나는 경우가 많다. 이 API가 뭐길래 이렇게 대화의 지분율을 다 차지하는걸까?
API란?
정의는?
Application Programming Interface의 줄임말이다. 어? Interface? 이전 블로그 포스팅 내용인 interface를 본다면 알 수 있듯이 Interface는 협업자들의 약속이나 맹세와 같은 것이라고 했다.
그렇다면 Application Programming Interface은 소프트웨어 애플리케이션이 서로 통신하여 데이터, 특징 및 기능을 교환할 수 있도록 만든 인터페이스라는 뜻이 된다!
조금 말이 어려운 것 같으니 쉽게 설명을 해보자면 애플리케이션과 운영체제 또는 애플리케이션과 프로그래밍 언어가 제공하는 기능 사이에서 동작할 수 있는 상호작용을 도와준다.
비유를 하자면
요즘 더 매직스타라는 TV 프로그램에 빠져있다. 마술을 좋아하는 사람들이라면 꼭 한번 보길 바란다.. 진짜 신기하다.. 더 매직스타를 보기 위해서는 TV를 틀어야한다. 이때 TV를 리모컨의 버튼을 눌러서 TV를 켜고 리모컨을 통해서 더 매직스타 다시보기를 찾는 것이다.
이때 나와 TV 사이에 상호작용을 도와주는 리모컨이 바로 API와 같은 역할을 하는 것이다.
REST API란?
어라? API가 그런 역할인 것은 알겠는데 갑자기 이 친구는 무엇일까? 궁금한 사람들이 꽤 있을 것이다. 우리는 API가 어떤 역할을 하는지 알았을 뿐이다. 이 API를 만들 때 필요한 원칙이 있다. 그중 REST API라는 원칙에 대해서 알아보도록 하겠다.
정의는?
REST는 Representational State Transfer의 약자로 “자원의 표현으로 상태를 전달하는 것”이라고 해석할 수 있다. 영어를 못하기 때문에 간단하게 설명을 해보자면 리소스를 어떻게 하겠다 라는 것을 HTTP URI와 HTTP Method로 깔끔하게 표현하는 방식을 뜻한다.
때문에 REST는 HTTP를 잘 활용하기 위한 원칙이며, REST API는 이 원칙을 잘 준수해서 만든 API인 것이다.
설계 가이드는?
그렇다면 어떻게 만들어야할까? 말로만 하면 어렵겠지만 다행히도 우리에게는 설계 가이드라는 것이 존재한다.
- 리소스에 대한 행위는 HTTP Method(POST, GET, PUT, DELETE)로 표현
- /(슬래시)는 계층 관계를 나타낼 때 사용
- URI 마지막 문자에 /(슬래시)는 사용하지 않음
- URI에 _(underscore)는 사용하지 않음
- 영어 대문자보다는 소문자를 사용 ⇒ 가독성을 위해 긴 단어는 잘 사용하지 않음
- 동사가 아닌 명사를 사용 ⇒ 동사는 HTTP Method가 표현하기 때문
- URI에 파일의 확장자(.json, .JPGE)를 포함시키지 않음
RESTful API란?
다 끝난 줄 알았는데 이 녀석은 또 무엇일까? 라고 생각한 사람들이 분명 있을 것이다. 너무 겁먹지 말길 바란다. 이 친구는 이름에서도 알 수 있듯이 REST API와 거의 동일한 친구이다.
정의는?
RESTful API는 REST API 설계 가이드를 따라서 API를 만드는 것으로 REST API 설계 가이드에 따라 API를 만들어서 웹 서비스를 제공한다면 해당 웹 서비스는 RESTful하다 라고 표현한다! 다만 누군가 공식적으로 발표한 것은 아니다.
개발 원칙은?
-
자원을 식별할 수 있어야 한다.
URL 만으로 내가 어떠한 자원을 제어하려고 하는지 알 수 있어야 한다. 이때 자원의 위치는 물론 자원의 종류까지 알 수 있어야 하며, Server가 제공하는 정보는 JSON이나 XML 형태로 HTTP body에 포함되어 전송시킨다.
-
행위는 명시적이어야 한다.
REST는 아키텍쳐 혹은 방법론과 비슷하기 때문에 이 방식을 강제적으로 따르게 하지는 않는다. 때문에 POST나 GET을 사용해서 UPDATE나 DELETE를 해도 된다. 다만 REST에 부합하지 않으면 REST를 따른다고 할 수 없다.
-
자기 서술적이어야 한다.
데이터에 대한 메타정보만을 가지고 어떤 종류의 데이터인지 어떤 어플리케이션을 실행해야 하는지를 알 수 있다. 즉, 데이터 처리를 위한 정보를 얻기 위해서, 데이터 원본을 읽어야한다면 자기 서술적이지 못하다.
-
HATEOS(Hypermeida as the Engine of Application State)
클라이언트 요청에 대해 응답을 할 때, 추가적인 정보를 제공하는 링크를 포함할 수 있어야 한다. 서버는 클라이언트 응용 어플리케이션에 하이퍼링크를 제공하고 클라이언트는 이 하이퍼링크를 통해서 전체 네트워크와 연결된다. 즉, 서버가 독립적으로 진화할 수 있도록 서버와 서버, 서버와 클라이언트를 분리할 수 있게 해준다.
지금 4가지의 개발 원칙에 대해서 설명을 했는데 읽으면서 무슨 말인지 어렵다고 느끼는 사람들이 분명 있을 것이다. 그렇다면 분명 이런 얘기가 나올 것이다.
당최 무슨 소리인지도 모르겠는데 이런 방식으로 개발을 하라고?
하지만 실무에서는 이러한 방식으로 개발하는 것은 현실적으로 힘들다는 것을 안다. 특히 개발비용 대비 효과가 있는 것도 아니며 4번째 원칙은 구현이 매우 어렵다고 한다. 나도 직접 구현해보지 않아서 모르겠지만 듣기로는 어렵다고 한다..ㅎㅎ
그런데 이미 많은 사람들이 이러한 조건을 지키지 않아도 REST API라고 하기 때문에 HTTP API와 비슷한 의미로 쓰이고 있다고 한다.
HTTP API는 HTTP를 사용하여 소통하는 API로 흔히 아는 Open API, Kakao API 등 대부분의 API가 여기에 속한다.
하지만 위의 규칙들을 다 지켜야만 REST API라고 말할 수 있는 것이다!
정리하자면
API는 Application과 다른 시스템이 상호작용하기 위해 정한 규칙이다!
REST는 소프트웨어 프로그램 아키텍처의 형식 중 하나이며, REST API는 이러한 규칙을 지켜서 만든 API를 뜻한다!
