REST API란 무엇인가
- REST API에서 REST는 Representational State Transfer의 약자로 소프트웨어 프로그램 아키텍처의 한 형식이다.
- 즉, 자원을 이름(자원의 표현)으로 구현하여 해당 자원의 상태(정보)를 주고 받는 모든 것을 의미한다.
- 월드 와이트 웹(WWW)과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 개발 아키텍처의 한 형식이다.
- REST 기본적으로 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에 웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일이다.
REST의 구체적인 개념
- HTTP URI를 통해 자원을 명시하고, HTTP Method(POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD OPERATION을 적용하는 것을 의미한다.
- 즉, REST는 자원 기반의 구조(ROA: Resource Oriented Architecture) 설계의 중심에 Resource가 있고 HTTP MEthod를 통해 Resource를 처리하도록 설계된 아키텍쳐를 의미한다.
- 웹의 모든 자원에 고유한 ID인 HTTP URI를 부여한다.
우리는 왜 RESTful APIs를 만드는 것일까
- RESTful APIs 개발하는 가장 큰 이유는 Client Side를 정형화된 플랫폼이 아닌 모바일, PC, 어플리케이션 등 플랫폼에 제약을 두지 않는 것을 목표로 했기 때문이다.
- 즉, 2010년 이전만 해도 Server Side에서 데이터를 전달해주는 Client 프로그램의 대상은 PC 브라우저로 그 대상이 명확헀다. 그렇다 보니 그냥 JSP, ASP, PHP 등을 잉요한 웹페이지를 구성하고 작업을 진행하면 됐다.
- 하지만 스마트 기기들이 등장하면서 TV, 스마트폰, 태블릿 등 Client 프로그램이 다양화 되고 그에 맞춰 Server를 일일이 만다는 것이 꽤 비효율적인 일이 되어 버렸다.
- 이런 과정에서 개발자들은 Client Side를 전혀 고려하지 않고 메시지 기반, XML, JSON과 같은 Client에서 바로 객체로 치환 가능한 형태의 데이터 통신을 지향하게 되면서 Server와 Client의 역할을 분리하게 되었다.
REST의 구성
- 자원(Resource) - URL
- 행위(Verb) - HTTP Method
- 표현(Representations)
- 자원(Resource) URL
- 모든 자원에 고유한 ID가 존재하고, 이 자원은 Server에 존재한다.
- 자원을 구별하는 ID는 /orders/order_id/1 와 같은 HTTP URI이다.
- 행위(Verb) - HTTP Method
- HTTP 프로토콜의 Method를 사용한다.
- HTTP 프로토콜은 GET, POST, PUT, DELETE와 같은 메서드를 제공한다.
- 표현(Representation of Resource)
- Client가 자원의 상태(정보)에 대한 조작을 요청하면 Server는 이에 적절한 응답(Representation)을 보낸다.
- REST에서 하나의 자원은 JSON, XML, TEXXT, RSS 등 여러 형태의 Representation으로 나타낼 수 있다.
- 현재는 JSON으로 주고 받는 것이 대부분이다.
REST의 특징
a. 클라이언트/서버 구조
- 클라이언트는 유저와 관련된 처리를, 서버는 REST API를 제공함으로써 각각의 역할이 확실하게 구분되고 일괄적인 인터페이스로 분리되어 작동할 수 있게 한다.
- REST Server: API를 제공하고 비지니스 로직 처리 및 저장을 책임진다.
- Client: 사용자 인증이나 context(세션, 로그인 정보) 등을 직접 관리하고 책임진다.
- 서로 간 의존성이 줄어든다.
b. 무상태성(Stateless)
- REST는 HTTP의 특성을 이용하기 때문에 무상태성을 갖는다.
- 즉, 서버에서 어떤 작업을 하기 위해 상태정보를 기억할 필요가 없고 들어온 요청에 대해 처리만 해주면 되기 때문에 구현이 쉽고 단순해진다.
c. 캐시 처리 가능(Cacheable)
- HTTP라는 기존 웹표준을 사용하는 REST의 특징 덕분에 기본 웹에서 사용하는 인프라를 그대로 사용 가능하다.
- 대량의 요청을 효율적으로 처리하기 위해 캐시가 요구된다.
- 캐시 사용을 통해 응답시간이 빨라지고 REST Server 트랜잭션이 발생하지 않기 때문에 전체 응답시간, 성능, 서버의 자원 이용률을 향상 시킬 수 있다.
d. 자체 표현 구조(Self-descriptiveness)
- JSON을 이용한 메시지 포멧을 이용하여 직관적으로 이해할 수 있고 REST API 메시지만으로 그 요청이 어떤 행위를 하는 지 알 수 있다.
e. 계층화(Layered System)
- 클라이언트와 서버가 분리되어 있기 때문에 중간에 프록시 서버, 암호화 계층 등 중간매체를 사용할 수 있어 자유도가 높다.
f. 유니폼 인터페이스(Uniform)
- Uniform Interface는 HTTP 표준에만 따른다면 모든 플랫폼에서 사용이 가능하며, URI로 지정한 리소스에 대한 조작을 가능하게 하는 아키텍쳐 스타일을 말한다.
- URI로 지정한 Resource에 대한 조작을 통일되고 한정적인 인터페이스로 수행한다.
- 즉, 특정 언어나 기술에 종속되지 않는다.
RESTful이란
- HTTP와 URI 기반으로 자원에 접근할 수 있도록 제공하는 애플리케이션 개발 인터페이스이다. 기본적으로 개발자는 HTTP 메소드와 URI만으로 인터넷에 자료를 CRUD 할 수 있다.
- 'REST API'를 제공하는 웹 서비스를 'RESTful' 하다고 할 수 있다.
- RESTful은 REST를 REST 답게 쓰기 위한 방법으로, 누군가가 공식적으로 발표한 것은 아니다.
RESTful API 개발 원칙
a. 자원을 식벽할 수 있어야 한다.
- URL(Uniform Resource Locator)만으로 내가 어떤 자원을 제어하려고 하는 지 알 수 있어야 한다. 자원을 제어하기 위해서, 자원의 위치는 물론 자원의 종류까지 알 수 있어야 한다는 의미이다.
- Server가 제공하는 정보는 JSON이나 XML 형태로 HTTP body에 포함되어 전송 시킨다.
b. 행위는 명시적이어야 한다.
- REST는 아키텍쳐 혹은 방법론과 비슷하다. 따라서 이런 방식을 사용해야 한다고 강제적이지 않다. 기존의 웹 서비스처럼, GET을 이용해서 UPDATE와 DELETE를 해도 된다.
- 다만, REST 아키텍쳐에는 부합하지 않으므로 REST를 따른다고 할 수는 없다.
c. 자기 서술적이어야 한다.
- 데이터에 대한 메타정보만 가지고도 어떤 종류의 데이터인지, 데이터를 위해서 어떤 애플리케이션을 실행해야 하는 지를 알 수 있어야 한다.
- 즉, 데이터 처리를 위한 정보를 얻기 위해서, 데이터 원본을 읽어야 한다면 자기 서술적이지 못하다.
d. HATEOS(Hypermedia as the Engine of APplication State)
- 클라이언트 요청에 대해 응답을 할 때, 추가적인 정보를 제공하는 링크를 포함할 수 있어야 한다.
- REST는 독립적으로 컴포넌트들을 손쉽게 연결하기 위한 목적으로도 사용된다. 따라서 서로 다른 컴포넌트들을 유연하게 연결하기 위해선, 느슨한 연결을 만들어줄 것이 필요하다.
- 이때 사용되는 것이 바로 링크이다. 서버는 클라이언트 응용 애플리케이션에 하이퍼링크를 제공한다.
- 클라이언으는 이 하이퍼링크를 통해서 전체 네트워크와 연결되며 HATEOAS는 서버가 독립적으로 진화할 수 있도록 서버와 서버, 서버와 클라이언트를 분리 할 수 있게 한다.
| HTTP Method | 전송형태 | 설명 |
|---|---|---|
| GET | GET [request-uri]?query_string HTTP/1.1 | 요청 받은 URI의 정보를 검색하여야 응답한다. |
| HEAD | HEAD [request-uri] HTTP/1.1 | GET 방식과 동일하지만, 응답에 BODY가 없고 응답코드와 HEAD만 응답한다. 웹서버 정보확인, 헬스체크, 버전확인, 최종 수정일자 확인등으 용도로 사용된다. |
| POST | POST [request-uri] HTTP/1.1 Host:[Hostname] 혹은 [IP] Content-Lenght:[Length in Bytes] Content-Type:[Content Type][데이터] | 요청된 자원을 생성(CREATE)한다. 새로 작성된 리소스인 경우 HTTP헤더 항목 Location : URI주소를 포함하여 응답한다. |
| PUT | PUT [request-uri] HTTP/1.1 Host:[Hostname] 혹은 [IP] Content-Lenght:[Length in Bytes] Content-Type:[Content Type][데이터] | 요청된 자원을 수정(UPDATE)한다. 내용 갱신을 위주로 Location : URI를 보내지 않아도 된다. 클라이언트측은 요청된 URI를 그대로 사용하는 것으로 간주한다. |
| PATCH | PATCH [request-uri] HTTP/1.1 Host:[Hostname] 혹은 [IP] Content-Lenght:[Length in Bytes] Content-Type:[Content Type][데이터] | PUT과 유사하게 요청된 자원을 수정(UPDATE)할 때 사용한다. PUT의 경우 자원 전체를 갱신하는 의미지만, PATCH는 해당자원의 일부를 교체하는 의미로 사용한다. |
| DELETE | DELETE [request-uri] HTTP/1.1 Host:[Hostname] 혹은 [IP] | 요청된 자원을 삭제 할 것를 요청한다. |
| CONNECT | CONNECT [request-uri] HTTP/1.1 Host:[Hostname] 혹은 [IP] | 동적으로 터널 모드를 교환, 프록시 기능을 요청시 사용한다. |
| TRACE | TRACE [request-uri] HTTP/ 1.1 Host: [Hostname] 혹은 [IP] | 원격지 서버에 루프백 메시지 호출하기 위해 테스트용으로 사용한다. |
| OPTIONS | OPTIONS [request-uri] HTTP/ 1.1 Host: [Hostname] 혹은 [IP] | 웹서버에서 지원되는 메소드의 종류를 확인할 경우 사용한다. |
