REST 란?
REpresentational State Transfer, REST
REST(Representational State Transfer)는 월드 와이드 웹과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식이다. 이 용어는 로이 필딩(Roy Fielding)의 2000년 박사학위 논문에서 소개되었다. 필딩은 HTTP의 주요 저자 중 한 사람이다. 이 개념은 네트워킹 문화에 널리 퍼졌다.
엄격한 의미로 REST는 네트워크 아키텍처 원리의 모음이다. 여기서 ‘네트워크 아키텍처 원리’란 자원을 정의하고 자원에 대한 주소를 지정하는 방법 전반을 일컫는다. 간단한 의미로는, 웹 상의 자료를 HTTP위에서 SOAP이나 쿠키를 통한 세션 트랙킹 같은 별도의 전송 계층 없이 전송하기 위한 아주 간단한 인터페이스를 말한다. 이 두 가지의 의미는 겹치는 부분과 충돌되는 부분이 있다. 필딩의 REST 아키텍처 형식을 따르면 HTTP나 WWW이 아닌 아주 커다란 소프트웨어 시스템을 설계하는 것도 가능하다. 또한, 리모트 프로시저 콜 대신에 간단한 XML과 HTTP 인터페이스를 이용해 설계하는 것도 가능하다. 출처: 위키피디아
REST
는 한 마디로 정확히 정의하기 어려운 개념인 것 같다. 부분 부분을 하나 하나 살펴보면서 이해해보도록 하자.
REST의 기본 구조
REST는 다음의 세 가지 요소로 구성된다.
자원 (Resource)
- URI행위 (Verb)
- HTTP Method표현 (Representation)
REST는 제어할 자원을 표시한 URI
로 수행할 행위인 HTTP Method
를 보내어 그 결과를 표현
한다.
URI
Uniform Resource Identifier, URI
통합 자원 식별자(Uniform Resource Identifier, URI)는 인터넷에 있는 자원을 나타내는 유일한 주소이다. URI의 존재는 인터넷에서 요구되는 기본조건으로서 인터넷 프로토콜에 항상 붙어 다닌다. 출처: 위키피디아
URI
는 웹 상에 존재하는 어떤 자원의 주소이다. 경기도 안산시 상록구 사동이라는 주소를 가지는 곳은 지구상에서 단 한 곳인 것 처럼 URI는 웹 상에 존재하는 어떤 유일한 자원을 가리키는 주소이다.
예를 들어 지금 이 페이지의 URI는
https://nachwon.github.io/django/2017/11/06/rest-1.html
이며 어느 장소에서든 이 URI로 접속하면 지금 보고 있는 이 블로그 포스트로 오게 된다.
URI와 URL의 차이
URI는 Uniform Resource Identifier
이고,
URL은 Uniform Resource Locator
이다.
즉, URL은 어떤 자원의 위치를 나타내고 URI는 어떤 자원을 식별하기까지 한다.
URL은 URI에 포함되는 하위 개념이다.
https://nachwon.github.io/django/2017/11/06/rest-1.html
위 주소는 nachwon.github.io
라는 서버의 django/2017/11/06/
디렉토리 안에 있는 rest-1.html
파일을 나타내는 URL이다.
https://www.google.co.kr/search?q=hello+world
위의 주소에서 URL은 https://www.google.co.kr/search
까지 이다.
?q=
라는 식별자 뒤에 무엇이 오느냐에 따라 나타나는 결과가 달라지게 되기 때문에 ?q=hello+world
까지 포함한 주소는 URI이다.
요즘은 점점 URI를 더 많이 쓰는 추세라고 한다. URI가 더 큰 개념이기 때문에 잘 모르겠으면 URI라고 하면 된다고 한다.
REST에서의 URI
RESTful한 URI는 반드시 자원을 가리켜야 한다.
처음 장고를 배울 때를 생각해보자. 예를 들어 1번 글
을 삭제하는 기능을 만들 때 URI 패턴을 아래와 같이 설정해주었던 것을 기억해보자.
post/delete/1
위 URI로 접속하면 1번 포스트가 삭제된다. 이러한 URI 설정은 REST를 제대로 적용하지 않은 URI이다.
RESTful한 URI는 정보의 자원만을 나타내야하며 어떤 행위가 포함되지 않도록 해야한다.
post/1
위와 같은 URI는 1번 글
자원을 명확히 나타내는 URI이다. 이 자원에 대해 행할 행위는 URI에 포함시키는 것이 아닌 HTTP Method
를 통해 수행하게 된다.
HTTP Method
REST에서는 어떤 자원에 행할 수 있는 행위를 네 가지로 나타내며 이를 CRUD
라고 한다.
CRUD는 Create
, Read (Retrieve)
, Update
, Delete
의 첫 글자를 각각 따온 것이다.
CRUD는 각각 HTTP Method
의 POST
, GET
, PUT
, DELETE
에 대응된다.
METHOD | 역할 |
---|---|
POST | POST를 통해 해당 URI를 요청하면 리소스를 생성한다. |
GET | GET를 통해 해당 리소스를 조회하고 해당 도큐먼트에 대한 자세한 정보를 가져온다. |
PUT | PUT를 통해 해당 리소스를 수정한다. |
DELETE | DELETE를 통해 리소스를 삭제한다. |
지금까지 배운 장고에서는 GET과 POST 방식의 요청에 대해서만 다루었다.
그렇기 때문에 post/delete/1
이나 post/create/1
등 과 같은 URI 패턴을 새로 만들어 포스트를 삭제하거나 생성할 수 밖에 없었다.
이제 REST를 배우면 좀 더 명확하고 깔끔한 URI 설계가 가능하게 될 것이다.
예를 들어 1번 글
을 삭제하려 할 때 기존에는 다음과 같이 post/delete/1
라는 주소로 POST 요청을 보내어 글을 삭제하였다.
POST post/delete/1
REST에서는 똑같은 작업을 아래와 같이 수행한다.
DELETE post/1
post/1
이라는 자원으로 DELETE 요청을 보내는 것이다. 제어하려는 자원과 행하려는 행위가 명확히 구분되어 어떤 작업을 하려는 건지 직관적으로 이해할 수 있게 되었다.
Representation
자원의 URI에 특정 행위를 요청하면 그 결과로 Representation
을 응답 받는다.
어떤 자원의 Representation은 html
, xml
, text
, json
, rss
등 다양한 형태로 표현될 수 있다.
예를 들어 1번 글
의 내용을 확인하는 요청을 아래와 같이 보냈다고 생각해보자.
GET post/1
그 결과로 돌려받는 Representation은 아래와 같은 json
파일이 될 수 있을 것이다.
[
"post":{
"id": 1,
"title": "First Post",
"content": "Hello! This is the First Post!"
}
]
이어지는 포스트에서는 직접 RESTful 한 장고 프로젝트를 만들어보면서 REST에 대해 이해해보도록 한다.
Reference
lambdaexp 블로그: http://lambdaexp.tistory.com/39
Toastmeetup 블로그: http://meetup.toast.com/posts/92
조대협의 블로그: http://bcho.tistory.com/953