# API : REST [1/2]
현재 사용되는 다양한 API 아키텍쳐 중 가장 보편화된 REST 방식은, 굉장히 많은 부분에서 장점을 보유하고 있는 디자인이라는 평을 받고 있다.
먼저 REST는 REpresentational State Transfer을 의미하는데, 2000년도 Roy Fielding이라는 사람의 박사학위 논문에서 최초로 소개되었다고 한다.
REST 방식은 웹 아키텍쳐의 우수성을 최대한 활용할 수 있도록 만들어진 API 라는 평을 받고 있는데, 웹 서비스 뿐만 아니라 다양한 컴포넌트로 구성된 서비스들을 하나로 묶을 때 많이 사용되는 개념으로 인식되고 있다. (이해하기 어렵다면 우선 넘어가자)
정리하자면,
"Define the thing to make what to do"
-> HTTP URI로 정의된 자원을 'HTTP 방식 + 페이로드'로 정의한 API
라고 말할 수 있을 것 같다.
(페이로드라 함은 네트워크 패킷에서 몸통부분을 나타내는 말이라고 여길 수 있다. 이 부분은 하단에 설명하도록 하겠다)
(URI에 대해 잘 모르겠다면 이전 포스팅을 참조하면 좋을 것 같다)
자원이란 '처리되는 대상'을 의미하는데, JSON, XML 등의 문서나 jpg, avi 등의 비디오가 될 수도 있을 것이다.
웹 상에서 이러한 자원들은 'URI'를 통해 표현된다. URI는 특정 자원의 고유한 위치를 나타내기 때문에, 자원의 위치를 의미하는 유일한 주소가 된다.
예를 들어 http://www.youtube.com/user1/video라는 URI가 있다고 가정하면, 이를 통해 user1이라는 사용자가 등록한 video라는 파일을 명시하고 있다고 볼 수 있다.
REST API에서 사용되는 메소드는 다음과 같으며, 이는 CRUD(Create, Read, Update, Delete) 방식을 모두 매핑한다.
POST http://www.homepage.com/users Content-Type: application/json
{
"username" : "newuser",
"age" : "20"
}
- 쉽게 예시를 들자면, 이미지 리소스에 대한 처리와 문서 리소스에 대한 처리가 동일한 형태로 요청된다.
- 즉 '이전에 어떤 요청을 했는지에 대한 정보를 전혀 저장하지 않는다'
- 결국 각 REST API들은 모두 독립적으로 처리가 되는데, 위와 같이 Payload 등에서의 문맥 처리가 필요할 경우 클라이언트가 자체적으로 진행하며 이에 대한 정보를 서버에 저장하여 유지시키지는 않는다.
- 이는 웹브라우저에서 HTTP 캐시를 이용하거나 하는 동작을 그대로 사용할 수 있다는 것을 의미하는데, 만약 같은 URI에 대한 요청이 여러번 주어질 경우 URI 리소스를 매번 서버로 요청하지 않고 클라이언트의 HTTP 캐시에서 미리 가져온 정보를 반환할 수 있다.
- 별도의 주석이나 문서를 불필요하게 생각하며, 이름만 가지고도 세부적인 기능을 충분히 도출할 수 있도록 만든다.
- 서버는 클라이언트의 실행 문맥(Execution Context)을 알고 있을 필요가 전혀 없으며, 이는 클라이언트에서 독립적인 REST API 호출 및 사용이 가능함을 나타낸다.
- 이는 클라이언트와 서버 사이의 역할 분담이 명확해지는 효과를 가져오는데, 결국 일의 양이 줄어드는 장점을 갖는다(이에 대해 포프TV에서는 1+1 != 2라는 명언을 이용하여 과연 일의 양이 줄어들기까지 할까?하는 의문점을 제시하였다. 어찌되었든 각각의 역할 분담이 명확해진 장점만을 중점적으로 보이도록 한다)
- 클라이언트는 대상 서버에 직접 붙었는지, 혹은 중간에 존재하는 서버와 통신하는지를 전혀 알지 못한다.
- 위의 내용과 동일하다. 클라이언트는 독립적으로 동작하기 때문에 단순히 'API만 호출'할 뿐이기 때문에 사이에서 일어나는 일들에 대해서는 Don't care한 것이다.
- 이를 이용하면 Security 관리, Encrypt, Load balancing 등 다양한 보안 및 성능 개선의 효과를 가져올 수 있다.
- 이해하기 조금 어려울 수 있는 부분이므로 이러한 장점이 있다는 것 정도만 알고 넘어가자.
먼저 REST는 REpresentational State Transfer을 의미하는데, 2000년도 Roy Fielding이라는 사람의 박사학위 논문에서 최초로 소개되었다고 한다.
REST 방식은 웹 아키텍쳐의 우수성을 최대한 활용할 수 있도록 만들어진 API 라는 평을 받고 있는데, 웹 서비스 뿐만 아니라 다양한 컴포넌트로 구성된 서비스들을 하나로 묶을 때 많이 사용되는 개념으로 인식되고 있다. (이해하기 어렵다면 우선 넘어가자)
1. 정의
REST는 "HTTP URI로 잘 표현된 리소스(자원)에 대한 동작 및 행위를 HTTP 방식으로 정의하는데, 이 때 자원의 내용은 JSON, XML 등 다양한 언어로 표현될 수 있다 "정리하자면,
"Define the thing to make what to do"
-> HTTP URI로 정의된 자원을 'HTTP 방식 + 페이로드'로 정의한 API
라고 말할 수 있을 것 같다.
(페이로드라 함은 네트워크 패킷에서 몸통부분을 나타내는 말이라고 여길 수 있다. 이 부분은 하단에 설명하도록 하겠다)
2. 자원(리소스)
REST API의 수행 대상이 되는 자원은 URI로 정의한다.(URI에 대해 잘 모르겠다면 이전 포스팅을 참조하면 좋을 것 같다)
자원이란 '처리되는 대상'을 의미하는데, JSON, XML 등의 문서나 jpg, avi 등의 비디오가 될 수도 있을 것이다.
웹 상에서 이러한 자원들은 'URI'를 통해 표현된다. URI는 특정 자원의 고유한 위치를 나타내기 때문에, 자원의 위치를 의미하는 유일한 주소가 된다.
예를 들어 http://www.youtube.com/user1/video라는 URI가 있다고 가정하면, 이를 통해 user1이라는 사용자가 등록한 video라는 파일을 명시하고 있다고 볼 수 있다.
3. 메소드(방식, 행위)
REST API의 가장 큰 장점 중 하나는 '자원에 대한 행위가 일관적(Uniform)'이라는 것이다. 좀 더 풀어서 설명하면 'REST API가 다루는 대상 자원의 종류와 관련 없이(문서, 비디오, 음악, 이미지 등), 같은 메소드로 동작한다'는 뜻을 나타낸다.REST API에서 사용되는 메소드는 다음과 같으며, 이는 CRUD(Create, Read, Update, Delete) 방식을 모두 매핑한다.
- POST : 지정된 URI에 새로운 리소스를 생성한다.
- GET : 지정된 URI에서 리소스를 검색하고, 이를 가져온다.
- PUT : 지정된 URI에 리소스를 만들거나 대체한다.
- PATCH : 리소스 일부를 업데이트한다.
- DELETE : 지정된 URI의 리소스를 제거한다.
4. 메소드 사용 예시
리소스를 표현하는 URI와 HTTP 메소드를 사용하여 클라이언트가 서버로 특정 정보를 요청하는 메시지를 다음과 같이 구성할 수 있다.
GET www.homepage.com/images/main
추가로 jpg 파일을 요청하고 싶을 때에는 다음과 같이 구성할 수 있다.
GET www.homepage.com/images/main HTTP/1.1 Accept:image/jpg
/image/main이라는 리소스에 대한 정보를 요청하는 내용으로, HTTP 1.1 프로토콜을 사용하며 파일 형태는 jpg를 갖고 있다는 것을 나타낸다.
하지만 HTTP 메소드와 URI만 가지고는 사용자가 원하는 내용을 모두 포함하는데 한계가 있다. 만약 새로운 유저를 생성하기 위한 메소드를 REST API로 구성한다고 하면 다음과 같다.
POST http://homepage.com/users/newuser
호스트(서버)에 있는 users에 newuser라는 이름을 가진 사용자를 추가하라는 REST API이다. 사용자는 이름, 직업, 나이, 성별 등 다양한 특성을 가질 수 있는데, 위와 같은 단순한 POST 메소드로는 모든 정보를 담지 못하는 한계를 갖게 된다.
결국 이러한 세부 정보는 JSON, XML 등의 언어로 표현할 수 밖에 없는데, 이러한 표현 부분을
메소드의 바디(Body) 또는 페이로드(Payload)라고 한다. 이러한 페이로드 부분을 여러가지 언어로 표현하고 정의할 수 있다. 사용자는 페이로드를 해석하기 위한 방법으로 REST API 헤더 부분에 'Content-Type: application/json'과 같은 내용만 추가하면 된다.POST http://www.homepage.com/users Content-Type: application/json
{
"username" : "newuser",
"age" : "20"
}
5. REST API의 특징
5.1. Uniform
- REST API는 리소스에 상관없이 동일한 API 메소드를 갖는다.- 쉽게 예시를 들자면, 이미지 리소스에 대한 처리와 문서 리소스에 대한 처리가 동일한 형태로 요청된다.
5.2. Stateless
- REST API를 제공하는 서버(호스트)에서 수행되는 내용의 문맥(Context)를 저장하지 않는다.- 즉 '이전에 어떤 요청을 했는지에 대한 정보를 전혀 저장하지 않는다'
- 결국 각 REST API들은 모두 독립적으로 처리가 되는데, 위와 같이 Payload 등에서의 문맥 처리가 필요할 경우 클라이언트가 자체적으로 진행하며 이에 대한 정보를 서버에 저장하여 유지시키지는 않는다.
5.3. Cacheable
- HTTP 프로토콜을 사용하므로, 기존의 웹 인프라를 그대로 사용할 수 있다.- 이는 웹브라우저에서 HTTP 캐시를 이용하거나 하는 동작을 그대로 사용할 수 있다는 것을 의미하는데, 만약 같은 URI에 대한 요청이 여러번 주어질 경우 URI 리소스를 매번 서버로 요청하지 않고 클라이언트의 HTTP 캐시에서 미리 가져온 정보를 반환할 수 있다.
5.4. Self-descriptiveness
- REST API 메시지 그 자체로 내부 기능을 쉽게 이해할 수 있도록 만들어진다.- 별도의 주석이나 문서를 불필요하게 생각하며, 이름만 가지고도 세부적인 기능을 충분히 도출할 수 있도록 만든다.
5.5. Client-Server architecture
- REST API 서버는 클라이언트에게 단순히 API 제공의 의무만을 가진다.- 서버는 클라이언트의 실행 문맥(Execution Context)을 알고 있을 필요가 전혀 없으며, 이는 클라이언트에서 독립적인 REST API 호출 및 사용이 가능함을 나타낸다.
- 이는 클라이언트와 서버 사이의 역할 분담이 명확해지는 효과를 가져오는데, 결국 일의 양이 줄어드는 장점을 갖는다(이에 대해 포프TV에서는 1+1 != 2라는 명언을 이용하여 과연 일의 양이 줄어들기까지 할까?하는 의문점을 제시하였다. 어찌되었든 각각의 역할 분담이 명확해진 장점만을 중점적으로 보이도록 한다)
5.6. Layered System
- REST API는 Multi-Layer로 구성될 수 있다.- 클라이언트는 대상 서버에 직접 붙었는지, 혹은 중간에 존재하는 서버와 통신하는지를 전혀 알지 못한다.
- 위의 내용과 동일하다. 클라이언트는 독립적으로 동작하기 때문에 단순히 'API만 호출'할 뿐이기 때문에 사이에서 일어나는 일들에 대해서는 Don't care한 것이다.
- 이를 이용하면 Security 관리, Encrypt, Load balancing 등 다양한 보안 및 성능 개선의 효과를 가져올 수 있다.
5.7. Code on Demand
- 이 부분은 Optional한 내용인데, REST API는 서버로부터 수행 스크립트를 받아서 클라이언트처럼 행동할 수 있다는 것이다.- 이해하기 조금 어려울 수 있는 부분이므로 이러한 장점이 있다는 것 정도만 알고 넘어가자.
댓글
댓글 쓰기