API..API... 프로그래밍을 배우며 한 번 쯤은 꼭 들어봤을 단어이다. 도대체.. 이게 뭔가요???
API
개념
API는 Application Programming INterface의 준말. 즉 여러 프로그램들과 데이터베이스, 기능들의 상호 통신에 관한 규칙을 규정하고 도와주는 매개체이다. 간단히 말해, 프로그램과 데이터베이스 혹은 기능과 서로 소통할 수 있도록 해주는 메신저 라고 생각할 수 있다.
API 자체가 하나로 정해진 것이 아닌 단순한 약속에 따른 매개체인 만큼 업종, 회사마다 다양한 API가 존재하고 그만큼 다양한 메시지가 주고 받아진다.
여기서 가장 중요한 부분은 프로그램과 데이터베이스 혹은 프로그램 끼리를 서로 "연결" 할 수 있다는 부분이다. 이 연결을 통해 우리는 다양한 소프트웨어를 하나의 소프트웨어에서 활용한다거나 한군데에서 요청한 정보들을 다른 곳에서 본다던지의 기능들을 구현 할 수 있게 된다.
아직도 어렵나요...?
그렇다면 소프트웨어니 이런 말 빼고, 현실적인 것으로 설명해 봅시다.
만약 내가 친구랑 같이 있는데 이 친구가 다른 약속으로 인해 자리를 뜬 상황을 미국인 / 일본인 / 중국인 에게 설명해야 한다고 해봅시다.
이때 미국인에게는 영어로, 일본인에게는 일본어로, 중국인 에게는 중국어로 소통해야 별 문제 없이 소통이 가능하겠죠? (난 영어도 안되는데 이 사람 부럽네..)
이때 친구가 약속으로 자리를 떳다는 상황을 다양한 사람들에게 정보를 전달 해 준 내가 바로 API가 되는 것입니다. 이때 API라고 다 같은 API가 아니죠?
각각 국적에 맞게 다른 언어로 말하는 것이 바로 각각의 소프트웨어가 약속한 방식 대로 메시지를 보내주는, 소프트웨어 마다 다른 API를 쓰게 되는 것입니다.
REST
개념
REST는 Representational State Transfer 의 약자로 자원을 구분, 해당 자원의 상태를 주고 받는 것을 의미합니다. 이때 정보들은 HTTP URI(Uniform Resource Identifier)를 통해 명시합니다.
클라이언트가 자원의 상태에 대한 조작(데이터베이스의 정보 수정, 정보 처리 등이 해당되겠죠?)을 요청하면 서버는 이에 따른 적절한 응답을 보냅니다. 이때 전달 방식은 JSON 혹은 XML을 통해 주고 받는 것이 일반적이라고 하네요?
결국 REST는 HTTP URI를 통해 클라이언트와 서버의 통신 방식으로 HTTP Method를 통해 자원을 처리하도록 되어있습니다.
REST의 구성요소
- 자원: HTTP URI에 맞게 서버에 저장되어 있는 정보로 ID로 구분 할 수 있습니다.
- 행위: HTTP Method를 사용하며 GET, POST, PUT, DELETE와 같은 메서드를 제공합니다.
- 표현: 클라이언트가 자원의 상태에 대한 조작을 요청하면 서버은 이에 따른 응답을 보냅니다. 이는 위에 서 말했듯 JSON, XML을 비롯해 TXT, RSS 등도 가능합니다.
REST의 특징
- Uniform: URI라는 규칙을 통해 리소스에 대한 조작 등을 통일되고 한정된 인터페이스를 사용해 수행합니다.
- Stateless: 무상태성을 띕니다. 작업 정보를 저장하지 않고 요청시마다 처리만 수행합니다. 이로 인해 서비스의 자유도를 올리고 구현이 단순화 됩니다.
- Casheable: HTTP라는 기존 웹표준을 그대로 사용해 웹의 인프라를 그대로 사용 가능합니다. 따라서 HTTP의 캐싱 기능 적용이 가능합니다.
- Self-descriptiveness: 자체 표현 구조로 API 메시지만 보고도 이해 가능합니다.
- 클라이언트-서버 구조: API를 통해 소통하는 방식이기에 서버와 클라이언트가 구현해야 할 내용이 명확해지고 서로간의 의존성이 줄어듭니다.
- 계층형 구조: 다중 계층으로 구현 가능하며 보안, 암호화 계층 등을 추가해 구조상의 유연성을 만들 수 있고 네트워크 기반의 중간 매체를 사용할 수 있게 합니다.
장점
HTTP를 이용하기 때문에 별도의 인프라 구축이 필요없고 또한 HTTP의 기능을 확장한 것이기에 추가적 장점을 가질 수 있습니다. 또한 HTTP표준을 따르는 모든 플랫폼에 사용 가능하고 범용성을 보장합니다. 이런 장점들로 여러가지 서비스 디자인에서 생길 수 있는 문제들을 최소화 하고 서버-클라이언트 구조로 역할 분리도 간편합니다.
단점
하지만 결국 REST는 표준이 따로 정해져있지 않고 HTTP Method의 형태가 제한적이어서 한계가 있고 브라우저를 통해 테스트 할 일이 많다면 URL 수정으로 동작하는 것이 더 간편합니다. 또한 구형 브라우저의 동작이 어려울 수 있습니다.
REST API
개념
REST의 단점들을 해결하기 위해 REST를 기반으로 API를 개발한 것이 REST API 입니다.
API는 결국 약속이기 때문에 REST의 방식을 활용해 통신을 하는 방식을 새로이 만든 것이라고 할 수 있네요.
규칙
REST API는 몇가지 규칙이 존재합니다.
- URI는 동사보다는 명사, 대문자 보다는 소문자를 사용한다.
- 마지막에 슬래시를 포함하지 않는다.
- 언더바 대신 하이픈을 사용한다.
- 파일 확장자는 생략한다.
- 행위는 포함하지 않는다.
이와 같은 예시를 한번 볼까요?
https://blog.naver.com/vjekkyv/223497802491
저의 블로그 첫번째 게시물입니다. 여기에 보면 naver.com/ 뒤에 vjekkyv/ 가 있고 그 뒤에 숫자들이 있으면서 슬래시 없이 끝이 난 모습을 볼 수 있네요.
모든 문자가 소문자로 되어 있고 언더바가 없으며 게시물도 결국 하나의 파일인데 해당하는 확장자가 보이지 않습니다. 또한 이 게시물을 열어본다는 행위에 대한 내용도 없는 모습입니다.
RESTful API
개념
이와 같이 REST의 원리에 맞춰진 시스템을 RESTful 하다 라고 하고 이에 따라 REST API를 제공하는 웹 서비스를 RESTful 하다고 할 수 있다.
목표
RESTful의 목표는 이해하기 쉬운 REST API를 만드는 것으로 성능 향상이 아닌 일관적인 컨벤션을 통한 API의 이해도 및 호환성을 목표로 하기 때문에 성능이 중요할 땐 RESTful이 깨져도 상관이 없다고 합니다.
원칙
- 자원 식별이 용이해야 한다.
- 행위는 명시적이어야 한다.
- 자기 서술적이어야 한다.
- HATEOS(Hypermedia As The Engine Of Application State, 하이퍼미디어를 어플리케이션의 상태를 관리하기 위한 메커니즘으로 사용한다)
한계
하지만 이런 REST한 것을 준수하는 것은 현실적으로 힘들다. 특히 이렇게 정확한 규칙에 따라 작성하게 된다면 개발 비용이 많이 들어가는 것은 자명한데 이런 방식이 더 효과적인가 라는 물음에는 맞다고 답하기 어렵다고 한다. 하지만 이미 현재 사용하는 API들이 REST 함을 따르기도 하기에 HTTP API를 REST API라고 하기도 한다.
결론
API는 프로그램과 다른 프로그램 사이의 상호작용을 규칙에 따라 도와주는 매개체이다.
REST는 소프트웨어의 형식 중 하나이고 REST API는 이런 REST라는 형식을 준수하는 API 이다.
