REST란?
REpresentational State Transfer의 약자입니다.
이것은 장비간 통신을 위해 CORBA, RPC, SOAP등의 복잡한 방법을 사용하는 대신, 간단하게 HTTP를 이용하는 것이 목적입니다.
REST는 자원 지향 구조(Resource Oriented Architecture)로 웹 사이트의 이미지, 텍스트, DB 내용 등의 모든 자원에 고유한 URI를 부여합니다.
이 용어는 로이 필딩(Roy Fielding)의 2000년 박사학위 논문에서 소개되었습니다. (필등은 HTTP의 주요 저자중 한사람)
엄격한 의미로 REST는 네트워크 아키텍쳐 원리모음 입니다.
네트워크 아키텍처 원리란 자원을 정의하고 자원에 대한 주소를 지정하는 방법 전반을 말합니다.
CRUD
- Create : 생성(POST)
- Read : 조회(GET)
- Update : 수정(PUT)
- Delete : 삭제(DELETE)
위의 각 기능의 앞글자를 따서 위와같은 기능을 하는 것들을 CRUD라고 합니다.
이 기능에 대응하는 HTTP 메소드는 괄호안의 POST, GET, PUT, DELETE 입니다.
동일한 URL일 경우에도 메소드마다 기능이 다르게 이용 됩니다.
POST : http://localhost/api/user/홍길동
- 홍길동의 user정보를 생성합니다.
PUT : http://localhost/api/user/홍길동
- 홍길동의 user정보를 수정합니다.
GET : http://localhost/api/user/홍길동
- 홍길동의 user정보를 가져옵니다.
DELETE : http://localhost/api/user/홍길동
- 홍길동의 user정보를 제거합니다.
위와 같이 REST API 서버에서는 동일한 URL의 경우에도 메서드에 따른 각각의 비즈니스 로직을 동작하게 됩니다.
URL에 동사보다는 명사를 사용
예를들면 user를 추가하거나 가져오는 api에 대해서
GET /getUser/홍길동
POST /setUser/홍길동
위와같이 사용하는걸 동사를 사용한다고 볼 수 있습니다.
허나 위에 배운것과 같이 메서드의 뜻을 이해 했다면 동사를 붙여서 url을 여러개로 분리할 필요 없이 통일해서 사용할 수 있습니다.
메서드가 동사의 역할을 하기 때문입니다. 위의 예제를 아래와 같이 수정해보겠습니다.
GET /user/홍길동
POST /user/홍길동
GET메서드는 get을 의미할 것이고, POST 메서드는 생성을 의미하기로 우리는 위에서 공부했습니다.
하나를 알면 둘을 아는 분들이라면 PUT과 DELETE도 마찬가지로 동작한다는 걸 이해하실 것 입니다.
이로써 우리는 통일된 URL을 사용할 수 있습니다.
6가지를 충족하는 아키텍처 스타일
- Client-Server
- Stateless
- Cache
- Uniform Interface
- Layered System
- Code-On-Demand
저 단어만 봐서는 감이 잘 안옵니다. 하나씩 무엇인지 알아봅시다.
Client-Server
REST서버는 API를 제공합니다.
하나 혹은 여러 클라이언트에서 하나의 REST API를 이용할 수 있습니다.
REST 서버에서 비즈니스 로직 처리 및 저장을 책임집니다.
클라이언트의 경우 사용자 인증이나 컨택스트(세션, 로그인 정보) 등을 직접 관리하고 책임지는 구조로 REST 서버와 역할이 나뉘어 지고 있습니다.
Stateless
무상태성이라고도 합니다.
상태 정보를 저장하지 않고 각 API서버는 들어오는 요청만을 들어오는 메시지로만 처리하면 됩니다.
세션과 같은 컨텍스트 정보를 신경쓸 필요가 없기 때문에 구현이 단순해집니다.
Cache
캐쉬를 사용할 수 있습니다..
HTTP 프로토콜 표준에서 사용하는 Last-Modified태그나 E-Tag를 이용하면 구현할 수 있습니다.
캐쉬를 사용하게 되면 응답시간 뿐 아니라 REST 서버 트랜잭션이 발생하지 않기 때문에 전체 응답시간, 성능, 서버의 자원 사용률을 향상 시킬 수 있습니다.
Uniform Interface
REST는 HTTP 표준에만 따른다면, 어떤 기술이라던지 사용이 가능한 인터페이스 스타일입니다.
Layered System
클라이언트는 직접 최종서버에 붙었는지 등을 알수가 없습니다.
intermediary 서버 등을 통해서 로드밸런싱/공유 캐시등을 통해 확장성과 보안성을 향상 가능 합니다.
Code-On-Demand
서버로 부터 스크립트를 받아서 Client에서 실행하는 것입니다.
반드시 충족할 필요는 없습니다.
참고
http://yeoubi.net/blog/restful-api/ - yeoubi
http://bcho.tistory.com/953 - 조대협의 블로그
https://speakerdeck.com/leewin12/rest-api-seolgye - leewin12 - RestAPI 설계
마치며
HTTP Basic의 마지막 세션 RESTful 까지 알아보았습니다.
다음 포스트 주제 JavaScript 카테고리로 돌아오겠습니다.