HTTP URI를 통해 Resource를 명시하고, HTTP Method(Post, Get, Put, Delete)를 통해 해당 Resource에 대한 CRUD Operation을 적용한다. 즉, REST는 ROA(Resource Oriented Architecture) 설계의 중심에 Resource가 있고 HTTP Method를 통해 Resource를 처리하도록 설계된 아키텍쳐를 의미한다.
HTTP Method와 CRUD Operation은 일반적으로 아래 표와 같이 맵핑된다.
2) SOAP와 비교
[일반적인 웹서비스]
[REST] URL로 요청
3) REST의 장점
- OPENAPI를 제공하기 쉽다.
- 멀티플랫폼 지원 및 연동이 용이하다.
- 원하는 타입으로 데이터를 주고받을수 있따. (XML, JSON, RSS )
- 기존 웹 인프라를(HTTP)를 그대로 사용가능하다 ( 방화벽, 장비 요건 불필요 )
- 사용하기 쉽다
- 세션을 사용하지 않는다. 각각의 요청에 독립적.
4) REST의 단점
- 표준이 없어서 관리가 어렵다.
- 사용할 수 있는 메소드가 4가지 밖에 없다.
- 분산환경에는 부적합하다.
- HTTP통신 모델에 대해서만 지원한다.
5) REST의 특징
- 클라이언트/서버 구조 : 일관적으로 독립되어야 한다.
- 무상태(Stateless) : 각요청 간 클라이언트의 Context는 서버에 저장되어서는 안 된다.
- 캐시가능(Cacheable) : WWW에서와 같이 클라이언트는 응답을 Caching 할 수 있어야 한다.
- 계층화(Layered System) : 클라이언트는 보통 대상 서버에 직접 연결 또는 중간 서버를 통 해 연결되는지 모른다.
- Code on demand(option) : 자바 애플릿/ 자바스크립의 제공으로 서버가 클라이언트가 실행 시킬 수 있는 로직을 전송하여, 기능을 확장 할수 있다.
- 인터페이스 일관성 : 아키텍처를 단순화하고, 작은 단위로 분리하여, 클라이언트-서버 파트 별로 독립적으로 개 선 될 수 있도록 한다.
- 자체 표현구조(Self-Descriptiveness) : API 메시지만 보고도 어떤 API인지를 이해 할수 있는 자체 표현 구조 를 가진다.
6) ROA란?
웹의 모든 리소스를 URI로 표현하고 구조적이고 유기적으로 연결하여 비 상태 지향적인 방법으로 정해진 method만을 사용하여 리소스를 사용하는 아키텍처
이는 4가지의 고유한 속성과 연관되어 진다. ( REST는 이 속성들을 지향한다 )
- Addressablilty
- Connectedness
- Statelessness
- Homogeneous Interface
+ Addressablilty (주소로 표현 가능함)
- 제공하는 모든 정보를 URI로 표시할 수 있어야 한다.
- 직접 URI로 접근할 수 없고 HyperLink를 따라서만 해당 리소스에 접근할 수 있다면 이는 RESTful하지 않은 웹서비스이다.
+ Connectedness (연결됨)
- 일반 웹 페이지처럼 하나의 리소스들은 서로 주변의 연관 리소스들과 연결되어 표현(Presentation)되어야 한다.
- 예를 들면,
<user>
<name>HJ</name>
</user> 는 연결되지 않은 독립적인 리소스이다.
<user>
<name>HJ</name>
<address>HJ/seoul/</address>
<phone>HJ/010</phone>
</user> 는 관련 리소스(address, phone)가 잘 연결된 리소스의 표현이다.
+ Statelessness (상태 없음)
- 현재 클라이언트의 상태를 절대로 서버에서 관리하지 않아야 한다.
- 모든 요청은 일회성의 성격을 가지며 이전의 요청에 영향을 받지 말아야 한다.
- 다시 또 코리아닷컴의 예를 들면 메일을 확인하기 위해 꼭 '..코리아닷컴../mailView.crd'에 접근하여 해당 세션을 유지한 상태에서 메일 리소스에 접근해야 한다. 이것이 바로 Statelessness가 없는 예이다.
- 세션을 유지 하지 않기 때문에 서버 로드 발란싱이 매우 유리하다.
- URI에 현재 state를 표현할 수 있어야 한다. (권장사항)
+ Homogeneous Interface (동일한 인터페이스)
- HTTP에서 제공하는 기본적인 4가지의 method와 추가적인 2가지의 method를 이용해서 리소스의 모든 동작을 정의한다.
- 리소스 조회 : GET
- 새로운 리소스 생성 : PUT, POST (새로운 리소스의 URI를 생성하는 주체가 서버이면 POST를 사용)
- 존재하는 리소스 변경 : PUT
- 존재하는 리소스 삭제 : DELETE
- 존재하는 리소스 메타데이터 보기 : HEAD
- 존재하는 리소스의 지원 method 체크 : OPTION
- 대부분의 리소스 조작은 위의 method를 이용하여 대부분 처리 가능하다. 만일 이것들로만 절대로 불가능한 액션이 필요할 경우에는 POST를 이용하여 추가 액션을 정의할 수 있다. (되도록 지양하자)
* supplement
- SOAP : HTTP, SMTP 등을 통해 XML 기반의 메시지를 컴퓨터 네트워크 상에서 교환하는 프로토콜
* Reference
- http://spoqa.github.io/2012/02/27/rest-introduction.html
- https://slipp.net/wiki/pages/viewpage.action?pageId=12878219#id-8주차-RESTAPI설계및구현-REST
- http://egloos.zum.com/killins/v/3092502
- http://www.hoons.net/Lecture/View/391
- http://www.seungdols.com/web/restful
- https://ko.wikipedia.org/wiki/REST
- http://www.iamcorean.net/22
0 개의 댓글:
댓글 쓰기