Intro

RESTful API라는 말은 정말 많이도 들어봤을 지 모른다.
누군가는 GraphQL로 RESTful 을 대체 하기도 하겠지만, 웹 기반 시스템에서 RESTful을 아예 배제하고 개발을 진행하기는 쉽지 않다.

이번 포스팅에서는 RESTful API의 특징과 장단점에 대해 알아보도록 하자.

Application Programming Interface

API는 Application Programming Interface의 약자다. 사실 이걸 굳이 해석을 해야할까 싶다. 해석 해도 똑같이 애플리케이션 프로그래밍 인터페이스다. 대체 할 한국어가 따로 없는 것 같다.

API는 애플리케이션 간 통신 규약이라고도 할 수 있다. 사실 애플리케이션 내에 로직들 간에 뭔가 통신 규약이라 할 법한 걸 가지고 있진 않다. 하지만 분리되어있는 프로그램 간에 데이터를 전달해야 한다면 얘기는 달라진다. 당장 MVC 구조에서 View에 데이터를 전달해야 할 때 View에서 Controller 에 Request가 전달된다. 그런 Request를 확인 한 후 Model로 명령이 전달되든 어떻게 되든 Response가 View에 전달 될 것이다.

이런 것 또한 API라고 볼 수는 있다. 엄연히 Model, View, Controller는 분리 되어있는 소프트웨어니까. 하지만 더 큰 의미로 생각 해 보면 API는 완전히 분리 된 애플리케이션 간에 통신에 사용된다. 비유를 하자면 리모콘과 TV의 관계를 생각 해볼 수 있다.

리모콘 내의 소프트웨어와 TV의 소프트웨어는 완전히 분리되어있다. 또한 완전히 다른 소프트웨어라 볼 수 있다. 하지만 리모콘에서 특정 버튼을 누름과 동시에 TV는 그 명령을 수행한다. 실제 API가 작동하는 방식과 동일하다.

API는 이렇게 다른 종류의 소프트웨어와 통신하고 서비스를 제공하는 역할을 한다. JAVA API든 Windows API든 여러가지 API가 존재한다. 실제로 우리는 JAVA API를 활용하여 다양한 클래스들을 직접 구현하는 게 아니라 불러다 쓸 수 있다.

System.out.println("Hello World!");

우린 이미 프로그래밍을 배우는 초창기부터 사실은 API를 쓰고 있었던 것이라 생각하면 편하다.

API의 종류는 정말 많다. 굳이 모두 서술하자면 그것만으로 장편 시리즈가 나올 것이다. 백엔드 개발자로써 가장 많이 다루게 될 API는 웹 API라고 할 수 있다.

웹 API는 웹 애플리케이션에서 다른 서비스에 요청을 보내고 응답을 받기 위해 정의 된 명세를 일컫는다. 위키백과에서도 알 수 있듯이 우리는 특정 웹 서비스를 사용하기 위해 반드시 그 웹서비스에 접속해서 직접 서비스를 이용 할 필요가 없다. 네이버 블로그 글은 네이버 API를 통해 자동으로 올리도록 프로그래밍 할 수도 있고, 지도 API를 통해 특정 작업이 이루어졌을 때 해당 위치를 알 수 있도록 프로그래밍 할 수도 있다.

RESTful?

Representational State Transfer의 약자다.
즉 자원을 이름으로 구분하여 해당 자원의 상태를 주고 받는 모든것을 의미한다.
HTTP의 메소드를 최대한 활용하여 사용할 수 있는 API다. 하지만 HTTP 메소드 그 자체를 사용하는 것이 전부는 아니다. RESTful 하다는 개념을 만족시켜야지만 비로소 RESTful API라고 할 수 있다.

RESTful API는 자원을 명시하고 HTTP 메소드를 통해 해당 자원에 대한 상태를 주고받는다.
정리하자면 아래와 같다.
1. HTTP URL을 통해 자원을 명시한다.
2. HTTP 메소드(GET, POST, PUT, DELETE) 를 통해 해당 자원에 대한 CRUD(Create, Read, Update, Delete) Operation을 정의한다.

CRUD에 대해 언급한 적이 있는 것 같지만 한번 더 정리하자면 CRUD Operation에는 각각 다음과 같은 HTTP 메소드를 사용한다.

• CREATE -> POST
• READ -> GET
• UPDATE -> PUT
• DELETE -> DELTE

물론 반드시 각각의 CRUD Operation에 해당 HTTP 메소드를 사용하지는 않는다. 상황에 따라 다르다. POST에 모든 정보를 집어넣어서 보내는 경우도 분명 존재하기는 하지만...우선은 일반적으로는 이렇게 쓴다는 것 정도는 알아두자.

REST의 구성요소

• Resource : HTTP URL
• Resource 에 대한 행위 (Verbs) : HTTP Method
• Resource 에 대한 행위에 대한 내용(Representations) : HTTP Message Payload 등이다.

REST의 특징

총 다섯가지 대표적인 특징들이 있다.

Server-Client(서버-클라이언트 구조)

당연한 얘기지만 서버 클라이언트 구조를 통해 API가 전달된다.

Stateless(무상태)

클라이언트와 서버 관계에서 서버가 클라이언트의 상태를 따로 보존하고 있지 않다는 의미다.
반대로 Stateful은 서버가 클라이언트의 상태를 보존한다는 의미.

Cacheable(캐시 처리 가능)

캐시가 사용 가능해야 한다는 것이다.
캐싱은 속도가 상대적으로 느린 시스템, 부하에 민감한 시스템의 앞에 가벼운 시스템을 주고 버퍼링과 같은 전략들을 이용하여 백엔드 시스템의 부하를 줄이고 속도를 높이는 방법이다.
RESTful API에서는 반드시 이런 캐시 기능을 지원해야 한다.
GET 같은 경우엔 브라우저 상에서 캐시 기능을 지원한다. 나머지 메소드들은 캐시를 적용할 수 없지만 POST의 경우는 Expires와 Cache Control Header를 이용하여 캐싱을 구현할 수 있다.

Layered System(계층화)

RESTful API를 구성하는 요소간에 계층이 존재해야 한다는 의미다.
API서버는 비즈니스 로직, 클라이언트는 클라이언트 역할, 미들 서버는 로드 밸런싱, 공유 캐시 등을 제공하는 등 각자 계층 별 역할에 충실하고 각자의 역할은 다른 계층에서 알 수 없다는 특징이 존재한다.

Uniform Interface(인터페이스 일관성)

Resource에 대한 요청을 통일되고 한정적으로 수행하는 아키텍쳐 스타일을 지원해야 한다는 의미다. 클라이언트가 플랫폼에 무관하며 특정 언어나 기술에 종속받지 않는 특징을 의미한다.
쉽게 생각해보면 HTTP 를 사용하는 모든 플랫폼은 Resource에 대한 요청을 보낼 수 있고 그러한 요청에 대한 응답을 모든 플랫폼에 제공할 수 있다는 의미다.
이러한 특징은 결합도를 낮춰주는 장점이 존재한다.

장단점

장점

• HTTP 프로토콜의 인프라를 그대로 사용하므로 REST API 사용을 위한 별도의 인프라를 구출할 필요가 없다.
• HTTP 프로토콜의 표준을 최대한 활용하여 여러 추가적인 장점을 함께 가져갈 수 있게 해 준다.
• HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하다.
• Hypermedia API의 기본을 충실히 지키면서 범용성을 보장한다.
• REST API 메시지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악할 수 있다.
• 여러 가지 서비스 디자인에서 생길 수 있는 문제를 최소화한다.
• 서버와 클라이언트의 역할을 명확하게 분리한다.

단점

• 표준이 자체가 존재하지 않아 정의가 필요하다.
• HTTP Method 형태가 제한적이다.
• 브라우저를 통해 테스트할 일이 많은 서비스라면 쉽게 고칠 수 있는 URL보다 Header 정보의 값을 처리해야 하므로 전문성이 요구된다.
• 구형 브라우저에서 호환이 되지 않아 지원해주지 못하는 동작이 많다.(익스폴로어)

사용 이유

서버 클라이언트가 각자 독립적으로 업데이트가 가능해진다. 만약 특정 API가 수정이 된다고 한들 클라이언트에서는 수정 할 것이 따로 없다.

Outro

지금까지 RESTful API의 개념, 특징과 장단점에 대해 알아보았다.
다음 포스팅은 RESTful API를 디자인하는 방법에 대해 포스팅 해 보도록 하겠다.

Reference

https://meetup.toast.com/posts/92
https://aws.amazon.com/ko/what-is/restful-api/
https://www.redhat.com/ko/topics/api/what-is-a-rest-api