간혹 iOS개발자 구인글을 보면 ‘REST API’ 혹은 ‘RESTful API’ 통신에 대한 이해 를 우대한다는 것을 쉽게 볼 수 있는데 이번 포스팅에서는 RESTful API에 대해서 알아보겠습니다.
개요
RESTful API는 Representational State Transfer의 약자로, 웹상에서 사용되는 자원을 이름(자원의 표현)과 행위(자원에 대한 행위)로 구분하여 해당 자원의 상태를 주고 받는 것을 의미한다.
Restful API의 특징
Uniform Interface(인터페이스 일관성)
RESTful API는 HTTP 표준 프로토콜을 사용하기 때문에, HTTP 표준 메소드(GET, POST, PUT, DELETE)를 이용하여 자원을 처리한다. 이러한 방식은 인터페이스 일관성을 제공하며, 서버와 클라이언트의 구현 방식에 독립적이므로, 서로간의 의존성이 줄어든다.
HTTP 표준 프로토콜이란?
HTTP 표준 프로토콜은 인터넷에서 데이터를 주고받을 수 있는 프로토콜(통신규약) 중 하나로, 클라이언트와 서버 간의 요청과 응답으로 이루어져 있습니다. RESTful API에서는 HTTP 표준 메소드(GET, POST, PUT, DELETE)를 이용하여 자원을 처리합니다.
Stateless(무상태성)
RESTful API에서 가장 중요한 특징 중 하나는 무상태성(Stateless)입니다.
무상태성은 서버가 클라이언트의 상태 정보를 저장하지 않는 것을 의미합니다. 예를 들어, 로그인을 한 후에도 서버는 사용자의 정보를 저장하지 않습니다. 이 방식은 서버의 확장성을 높이고, 서버의 부하를 줄여줍니다.
무상태성의 이점은 확장성과 유연성을 높여준다는 것입니다. 서버가 클라이언트의 상태 정보를 저장하지 않기 때문에, 서버는 더 많은 요청을 처리할 수 있으며, 사용자가 더 나은 서비스를 받을 수 있습니다.
무상태성은 클라이언트와 서버 간의 의존성을 줄여줍니다. 서버가 클라이언트의 상태 정보를 저장하지 않기 때문에, 클라이언트는 자유롭게 서버와 통신할 수 있습니다. 또한, 서버는 클라이언트의 상태 정보를 저장하지 않기 때문에, 클라이언트의 상태 정보가 바뀌더라도 서버는 이를 신경 쓰지 않아도 됩니다.
따라서, RESTful API는 서버와 클라이언트 간의 의존성을 줄이고, 서비스의 확장성과 유연성을 높여주는 중요한 기술입니다.
Cacheable(캐시 처리 가능)
RESTful API는 HTTP 프로토콜을 사용하기 때문에, HTTP의 캐시 기능을 사용할 수 있습니다. 이러한 방식은 클라이언트의 성능을 향상시키며, 서버의 부하를 줄여줍니다. 이를 통해 클라이언트와 서버간의 더욱 원활한 소통이 가능해집니다.
HTTP 프로토콜에서 캐시 기능은 클라이언트가 이미 가져온 자원을 다시 서버에서 가져오지 않고, 로컬에 저장해두어 다음에 같은 자원을 요청할 때 서버에 다시 요청하지 않고 로컬에서 바로 가져오는 것입니다. 이를 통해 클라이언트와 서버 간의 통신 횟수를 줄이고, 클라이언트의 성능을 향상시킵니다.
Self-descriptiveness(자체 표현 구조)
Restful API는 메시지에 자원 상태 정보를 포함하여 전송하기 때문에, 메시지만으로도 자원(Resource)에 대한 이해가 가능합니다. 이러한 방식은 서버와 클라이언트의 구현 방식에 독립적이며, 서로 간의 의존성이 줄어듭니다. 이는 RESTful API를 사용하는 시스템의 유연성과 확장성을 높입니다.
예를 들어, RESTful API를 사용하여 블로그 포스트를 작성하는 경우를 생각해보겠습니다. 클라이언트는 블로그 포스트를 생성하기 위해 POST 메소드를 사용하여 서버에 요청합니다.
이때, 클라이언트는 생성하려는 블로그 포스트의 정보를 메시지 바디에 담아서 서버에 전송합니다. 서버는 이 정보를 받아서 새로운 블로그 포스트를 생성하고, 생성된 블로그 포스트의 ID를 메시지로 응답합니다.
이러한 방식에서 클라이언트는 생성된 블로그 포스트의 ID를 얻어서, 이후에 블로그 포스트를 수정하거나 삭제할 때 사용할 수 있습니다. 이렇게 클라이언트는 RESTful API를 사용하여 서버에서 자원에 대한 상태 정보를 전송받을 수 있습니다.
Client-Server Architecture(클라이언트-서버 구조)
RESTful API는 클라이언트와 서버 간의 분리를 지원합니다. 이러한 방식은 서버의 확장성을 높이고, 클라이언트와 서버 간의 의존성을 줄여줍니다. 또한, 이러한 아키텍처는 RESTful API를 사용하는 시스템의 보안성을 높이는 데 도움을 줍니다. 클라이언트와 서버 간의 구분은 각각의 역할을 명확히 하며, 보안 이슈를 해결하는 데 도움이 됩니다.
예를 들어, 클라이언트는 서버에 요청을 보내어 자원(Resource)을 받아오지만, 이때 서버는 요청을 받아 자원을 반환하는 역할만을 수행하며 클라이언트와 상호작용하지 않습니다. 이러한 방식은 RESTful API를 사용하는 시스템의 보안성을 높이는데 도움을 줍니다.
구체적인 예시로, 인터넷 뱅킹 시스템을 사용하는 경우를 생각해보겠습니다. 클라이언트가 인터넷 뱅킹 시스템에 로그인하면, 서버는 클라이언트에게 은행 계좌 정보를 반환합니다. 이때 서버는 클라이언트의 요청을 받아 은행 계좌 정보를 준비하고 반환하는 역할만을 수행합니다. 클라이언트는 이 정보를 사용하여 계좌 잔액을 확인하거나 거래를 수행할 수 있습니다.
이러한 방식에서 클라이언트와 서버는 각각의 역할을 명확히 하며, 서로 간의 의존성이 줄어듭니다. 이는 RESTful API를 사용하는 시스템의 유연성과 확장성을 높입니다.
Restful API의 구성 요소
자원(Resource)
RESTful API에서 자원은 URI로 표현된다. 모든 자원은 고유한 ID를 가지며, 이 ID는 URI의 일부로 사용됩니다.
URI vs URL 뭐가 다른거지?
URI(Uniform Resource Identifier)와 URL(Uniform Resource Locator)은 비슷한 개념이지만, 약간의 차이가 있습니다.
URI는 인터넷에서 특정 자원을 나타내는 문자열입니다. URI는 URL과 URN(Uniform Resource Name) 두 가지 유형으로 나뉩니다.
URL은 인터넷에서 특정 자원의 위치를 나타내는 문자열입니다.
URL은 일반적으로 "http://" 또는 "https://"와 같은 프로토콜과 "www.example.com"과 같은 호스트 이름, 그리고 자원의 경로와 파일 이름으로 구성됩니다.
URN은 인터넷에서 특정 자원의 이름을 나타내는 문자열입니다. URN은 URL과 달리 자원의 위치를 나타내지 않습니다. 대신, URN은 일반적으로 자원의 이름과 버전 번호를 포함합니다.
따라서, URL은 URI의 하위 집합이며, URI는 인터넷에서 특정 자원을 식별하는 데 사용되는 모든 문자열을 포함하는 더 넓은 개념입니다.
예를 들어, http://www.example.com/index.html 이라는 URL은 http 프로토콜을 사용하며, 호스트 이름은 www.example.com이고, 포트 번호는 생략되어 있으며, 자원 경로는 /index.html 입니다. 이 URL은 http 프로토콜을 사용하는 웹 서버에서 호스팅되는 index.html이라는 파일을 가리킵니다.
이 URL은 http://www.example.com/about.html이라는 다른 URL과 구분됩니다. 또한, 이 URL은 URI의 일종이며, 자원의 위치와 특성을 나타내는 정보를 포함합니다.
행위(Verb)
RESTful API에서 행위는 HTTP 프로토콜의 메소드(GET, POST, PUT, DELETE)로 표현됩니다. 예를 들어, 블로그 포스트를 생성하기 위해서는 클라이언트가 POST 메소드를 사용하여 서버에 요청하고, 생성된 블로그 포스트를 수정하거나 삭제하기 위해서는 클라이언트가 각각 PUT, DELETE 메소드를 사용하여 서버에 요청합니다. 이러한 방식은 사용자가 자원을 다루는 데 필요한 행위를 HTTP 프로토콜의 메소드를 이용하여 표현할 수 있도록 하며, 인터페이스 일관성을 제공합니다.
RESTful API에서 자원의 상태 정보는 XML, JSON 등의 Representation으로 전송됩니다.
예를 들어, 클라이언트에서 RESTful API를 사용해 블로그 포스트를 작성하고자 할 때, 클라이언트는 HTTP POST 메소드를 사용하여 서버에 요청을 보냅니다. 이때, 클라이언트는 작성하려는 블로그 포스트의 정보를 XML 또는 JSON 등의 Representation 형태로 메시지 바디에 담아서 전송합니다.
서버는 클라이언트의 요청을 받아, 메시지 바디에서 블로그 포스트의 정보를 추출하여 데이터베이스에 저장합니다. 이후, 서버는 생성된 블로그 포스트의 ID를 XML 또는 JSON 등의 Representation 형태로 응답합니다. 클라이언트는 이후에 블로그 포스트의 ID를 사용하여 블로그 포스트를 수정하거나 삭제할 수 있습니다.
이러한 방식에서 자원(Resource)의 상태 정보는 XML, JSON 등의 Representation 형태로 전송되므로, 클라이언트와 서버 간의 구현 방식에 독립적이며, 서로 간의 의존성이 줄어듭니다. 이는 RESTful API를 사용하는 시스템의 유연성과 확장성을 높입니다.
Restful API의 예시
GET Method
GET 메소드는 URI로 지정된 자원을 조회한다.
예를 들어, http://api.example.com/user/123 URI를 사용하여 ID가 123인 사용자 정보를 조회할 수 있습니다.
POST Method
POST 메소드는 URI로 지정된 자원을 생성한다.
예를 들어, http://api.example.com/user URI를 사용하여 새로운 사용자를 생성할 수 있습니다.
PUT Method
PUT 메소드는 URI로 지정된 자원을 수정한다.
예를 들어, http://api.example.com/user/123 URI를 사용하여 ID가 123인 사용자 정보를 수정할 수 있습니다.
DELETE Method
DELETE 메소드는 URI로 지정된 자원을 삭제한다.
예를 들어, http://api.example.com/user/123 URI를 사용하여 ID가 123인 사용자 정보를 삭제할 수 있습니다.
마무리
RESTful API는 HTTP 프로토콜을 기반으로 한 인터페이스이며, 자원(Resource), 행위(Verb), 표현(Representation)으로 구성된다. 이러한 방식은 인터페이스 일관성, 무상태성, 캐시 처리 가능, 자체 표현 구조, 클라이언트-서버 구조의 특징을 가지며, HTTP 프로토콜의 메소드(GET, POST, PUT, DELETE)를 이용하여 자원을 처리한다. Restful API를 이용하면 서버와 클라이언트간의 의존성을 줄이면서, 확장성과 유연성을 높일 수 있다.
REST API와 RESTful API는 서로 비슷한 개념이지만, 서로 다르다. REST API는 웹 상의 자원을 표현하고, 그 자원에 대한 메소드를 제공하는 것이다. RESTful API는 REST API를 따르는 API를 의미한다. 즉, RESTful API는 REST API의 디자인 원칙을 모두 따르는 API를 의미한다.