HTTP Method와 CRUD Operation은 일반적으로 아래 표와 같이 맵핑된다.
![Screen-shot-2013-09-23-at-%25EC%2598%25A4%25ED%259B%2584-11.52.23.png](https://3.bp.blogspot.com/-9y5AxEVlixA/VqgiCoiy8iI/AAAAAAAAABM/qxzN2UVQawk/s400/Screen-shot-2013-09-23-at-%25EC%2598%25A4%25ED%259B%2584-11.52.23.png)
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