RESTFUL(Representational Safe Transfer)

  이번 게시물은 많은 블로그들의 내용을 저에게 보기 좋게, 이해하기 쉽게 옮긴 것입니다. 수정 없이 복사해 온 것은 바로 아래에 출처를 남겼으며 수정 후 게시한 것들은 본 게시물 하단에 출처를 기록하였습니다.

REST가 나타난 이유

  REST는 웹의 창시자(HTTP) 중의 한 사람인 Roy Fielding의 2000년 논문에 의해서 소개되었다. 현재의 아키텍쳐가 웹의 본래 설계의 우수성을 많이 사용하지 못하고 있다고 판단했기 때문에, 웹의 장점을 최대한 활용할 수 있는 네트워크 기반의 아키텍쳐를 소개했는데 그것이 바로 Representational safe transfer (REST)이다.

조대협의 블로그

REST에서 가장 중요하며 기본적인 규칙

• URI는 정보의 자원을 표현해야 한다.
• 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE 등)으로 표현한다.

  이 외에도 PATCH 라는 HTTP Method에도 주목하시기 바랍니다. PUT이 해당 자원의 전체를 교체하는 의미를 지니는 대신, PATCH는 일부를 변경한다는 의미를 지니기 때문에 최근 update 이벤트에서 PUT보다 더 의미적으로 적합하다고 평가받고 있습니다. Rails도 4.0부터 PATCH가 update 이벤트의 기본 Method로 사용될 것이라 예고하고 있습니다.

spoqa 기술 블로그

HTTP post/get Idempotent

HTTP 메서드	REST에서의 의미	Idempotent
POST	Create	No
GET	Select	Yes

GET, POST의 근본적인 특성 차이는 GET은 idempotent, POST는 non-idempotent 하다는 점이다.

멱등(idempotent) 수학 용어로 해당 연산을 해도 결과에 변화가 없다는 특성을 표현하는 말이다. Idempotent는 여러 번 수행을 해도 결과가 같은 경우를 의미한다.

예시

1. 100 x 1 = 100 이므로, 곱셈에대해 1을 멱등원 이라고 부르며 이러한 1을곱하는 연산이 멱등 연산이다.

2. a++는 Idempotent 하지 않다고 하지만(호출시마다 값이 증가 되기 때문에), a=4와 같은 명령은 반복적으로 수행해도 Idempotent하다. (값이 같기 때문에) 

POST 연산의 경우에는 리소스를 추가하는 연산이기 때문에, Idempotent하지 않지만 나머지 GET,PUT,DELETE는 반복 수행해도 Idempotent 하다. GET의 경우 게시물의 조회수 카운트를 늘려준다던가 하는 기능을 같이 수행했을 때는 Idempotent 하지 않은 메서드로 정의해야 한다.

  Idempotent의 개념에 대해서 왜 설명을 하냐 하면, REST는 각 개별 API를 상태 없이 수행하게 된다. 그래서, 해당 REST API를 다른 API와 함께 호출하다가 실패하였을 경우, 트렌젝션 복구를 위해서 다시 실행해야 하는 경우가 있는데, Idempotent 하지 않은 메서드들의 경우는 기존 상태를 저장했다가 다시 원복해줘야 하는 문제가 있지만, Idempotent 한 메서드의 경우에는 반복적으로 다시 메서드를 수행해주면 된다. 이러한 뜻을 HTTP요청 메서드를 해석하는데 적용해보면,GET은 해당 요청을 몇번을 수행해도 해당 요청에 대한 결과가 계속 동일하게 돌아오는 것을 의미하며, POST는 해당 요청이 수행되면 서버에서 무언가 바뀌고, 동일한 결과가 돌아오는 것을 보장할 수 없다는 것을 의미한다.

  즉 GET을 이용하여 게시판에 글을 쓴다면(글을 쓴다는 동작은 서버에 데이터가 바뀌고 다른 결과가 돌아 올 수 있다는 것을 의미) 이것은 GET의 idempotent 특성을 무시하는 것이며 문제 발생의 여지가 있다.

예를 들어 게시물 조회를 하는 API가 있을때, 조회시 마다 조회수를 올리는 연산을 수행한다면 이 메서드는 Idempotent 하다고 볼수 없고, 조회하다가 실패하였을 때는 올라간 조회수를 다시 -1로 빼줘야 한다. 즉 Idempotent 하지 않은 메서드에 대해서는 트렌젝션에 대한 처리가 별다른 주의가 필요하다.

REST의 리소스

  REST는 리소스 지향 아키텍쳐 스타일이라는 정의 답게 모든 것을 리소스 즉 명사로 표현을 하며, 각 세부 리소스에는 id를 붙인다. 사용자라는 리소스 타입을 http://myweb//users라고 정의했다면, terry라는 id를 갖는 리소스는 http://myweb/users/terry 라는 형태로 정의한다. REST의 리소스가 명사의 형태를 띄우다 보니, 명령(Operation)성의 API를 정의하는 것에서 혼돈이 올 수 있다.

  예를 들어서 “Push 메서지를 보낸다”는 보통 기존의 RPC(Remote Procedure Call)이나 함수성 접근해서는 /myweb/sendpush 형태로 잘못 정의가 될 수 있지만, 이러한 동사형을 명사형으로 바꿔서 적용해보면 리소스 형태로 표현하기가 조금더 수월해 진다. “Push 메시지 요청을 생성한다.”라는 형태로 정의를 변경하면, API 포맷은 POST/myweb/push 형태와 같이 명사형으로 정의가 될 수 있다. 물론 모든 형태의 명령이 이런 형태로 정의가 가능한 것은 아니지만, 되도록이면 리소스 기반의 명사 형태로 정의를 하는게 REST형태의 디자인이 된다. 

	REST	RPC
메세지	“Push 메시지 요청을 생성한다.”	“Push 메서지를 보낸다”
정의	POST/myweb/push	/myweb/sendpush

< REST API의 간단한 사용자 생성 예제 >

1. 리소스 : http://myweb/users

2. 내용(메시지) : 이름은 terry, 주소는 seoul 

3. 메소드 : HTTP Post

HTTP Post, http://myweb/users/

{  

   "name":"terry",

   "address":"seoul"

}

조대협의 블로그

리소스	POST	GET	PUT	DELETE
	create	read	update	delete
/dogs	새로운 dogs 등록	dogs 목록을 리턴	bulk로 여러 dogs 정보를 업데이트	모든 dogs 정보를 삭제
/dogs/baduk	에러	baduk 이라는 이름의 dogs 정보를 리턴	baduk이라는 이름의 dogs 정보를 업데이트	baduk 이라는 이름의 dogs 정보를 삭제

조대협 블로그

GET    /items            #=> index
GET    /items/1          #=> show
GET    /items/new        #=> new
GET    /items/1/edit     #=> edit
PUT    /items/1          #=> update
POST   /items            #=> create
DELETE /items/1          #=> destroy




---

출처 및 참고

1. post, get 동작과정

[참고] http://egloos.zum.com/dkbalm/v/769595

2. HTTP post/get의 근본적인 개념

[출처] http://www.letmecompile.com/get-post-%EB%B0%A9%EC%8B%9D-%EC%B0%A8%EC%9D%B4%EC%A0%90/

3. HTTP request 요청 시 Content-Type의 중요성

[참고] http://lng1982.tistory.com/225

4. HTTP Packet 분석

[참고] http://darksoulstory.tistory.com/68

5. angular HTTP API

[참고] https://angular.io/docs/js/latest/api/http/index/Http-class.html

6. 조대협 블로그

[출처] http://bcho.tistory.com/954

7. spoqa 기술 블로그 (HTTP HEADER, HTTP 상태코드 등등)

[출처] https://spoqa.github.io/2013/06/11/more-restful-interface.html

8. 전체적인 RestFul

[참고] http://www.slideshare.net/ssuser7887b3/restful-api

https://meetup.toast.com/posts/92