RESTful API의 Resource 원형과 Method란 무엇일까?

(참조 : sabarada.tistory.com/27)

RESTful API에서 일반적으로 Resource라고 부르는 요소에 대해 정리해보자.

 

모든 정보들을 리소스라고 부른다. 이미지, 일반적 서비스, 문서 리소스들의 집합 등.

특정 시점의 리소스 상태를 리소스 표현이라고 부른다.

 

resource representation(리소스 대표)에는 데이터(자료), 메타데이터(목적을 위해 만든 자료)

그리고 상태를 변경하는 하이퍼링크 등이 있다고 한다

 

리소스의 특징은 하이퍼링크의 표현이다.

이전에는 하이퍼링크를 다른 사이트로 이동할때 쓰는 것이라고 알고 있지만, 

RESTful API에서는 정보의 표현과 제어를 동시에 활용하고 있다.

 

각 시스템에서 이해할 수 있는 형식, 관계 타입에 갖추어 hypertext를 통한 link로

사용한다면 REST한 표현이라고 한다.

 

또, resource method도 중요한 요소이다.

get/put/post/delete로 표현하고 이를 미디어 타입이라고 한다.(사실 꼭 이게 아니더라도 공용된 표현이면 된다.)

 

일반적으로 사용되는 미디어 타입(method)의 표기에는 

GET - 읽기 

POST - 쓰기 (때때로 읽기인데 보안과 관련된 문제는 POST로 표기한다) 

PUT - 업데이트

PATCH - 부분 업데이트

DELETE - 삭제

 

즉, 하이퍼텍스트를 통해 어떤 것인지 표현하고, 미디어 타입(method)로 동작을 표현한다.

여기서 하이퍼 텍스트란?  HTML이나 XML, JSON등을 이용한 방법을 말하지만, 그 외에도 각 시스템에서 *이해할 수 있는 형식, 관계 타입을 갖추어 hypertext를 통한 link로 사용한다면 그것은 REST하다고 할 수 있다.

 

또, 리소스 원형에 대해서도 이해해야한다. 

도큐먼트 - row 단위의 리스트 컬렉션의 하나의 객체단위로 단일 정보를 포함하고 있는 데이터

컬렉션 - 도큐먼트들의 집합니다. 관리 주체는 서버, 컬렉션은 클라단에서 새로운 리소스를 제안해서 올릴수도 있지만, 결정은 서버가 한다.

스토어 - 백엔드 입장에선 창고이다. 컬렉션과 같이 도큐먼트들의 집합이며 관리 주체는 클라이언트이다. 클라이언트는 기존의 리소스를 스토어에 추가하거나 삭제 변경 할 수 있다.

컨트롤러 : 컬렉션, 스토어의 메서드(함수) 기능이다. Http method(curd)를 제외한 특정한 기능을 요구 할 때 사용한다.

 

내가 이해한 바로는, 도큐먼트들은 하나의 요소이며, 컬렉션은 하나의 묶음이다. 단. 주체가 서버이다.

스토어는 주체가 클라이언트(엔드포인트 혹은 프론트)인 묶음이며, 컨트롤러는 기능을 동작하는 함수이다.

 

리소스 원형을 url에 표현하기위해서는...

도큐먼트는 단수 명사로 표현하고, 컬렉션과 스토어는 복수 명사를 사용한다.

컨트롤러나 동사는 동사구야한다고 한다.

 

즉, /users/pym505/sleep 라고 표현을 한다면. 유저라는 묶음(컬렉션)중에 pym505라는 객체(도큐먼트)가

잠을 자는 기능을 하는 api의 주소를 표현했다고 할 수 있다.

 

이 경우에는 pym505의 상태 변경을 하는 것이니 PUT 혹은 PATCH로 표현 할 수 있다.

 

대충 내가 이해한 바로는 위와 같다.

 

단, 이를 넘어서 추상적으로 생각하여 이해하지 않으면 안된다.

지금 생각은 RESTful API에서의 이론이지만, 실제로 MongoDB또한 리소스 원형의 형태를 채용하고 있고,

개발을 넘어 이해를 한다면 내가 어떤 상황에 와서도 응용을 할 수 있게 되기 때문에 하나의 개념으로 생각하고 이해해야한다고 한다.

 

예를 들어 꿀단지가 있다면 안에 있는 꿀은 도큐먼트이고, 단지는 컬렉션이다. 꿀을 푸는 스푼은 스토어가 될 수도 있고, 그와 동시에 컨트롤러가 될 수도 있는 것이다. 

 

또, 꿀 안에는 아밀라아제나 당같은(사실 성분 아에 모른다.) 꿀의 요소가 하나하나씩 도큐먼트, 관점을 바꾸면 꿀 자체가 컬렉션이 될 수 있는 것이다. 

 

이는 내가 생각하기에 JSON 객체와 유사한 구조를 가지고 있는것처럼 생각된다.

일단 내가 생각하기에 위와 같이 정리할 수 있었다.

 

RESTful API의 규칙과, 리소스 원형에 대한 지식, method의 표현법을 활용한다면

어떠한 구조를 설계할 때, 인풋과 아웃풋을 명확히 구별하여 독립적인 기능을 가지고, 재활용 할 수 있는 유연한 어플리케이션을 일관성있게 표현하는게 가능할 것이다.