본문 바로가기
기타/기타

[REST API] REST에서의 Resource

by 사바라다 2019. 9. 29.
반응형

REST API에 대해서 제대로 알고 싶다라는 생각에 찾아보던 중 괜찮다고 느껴진 사이트가 있습니다. 바로 https://restfulapi.net 이라는 사이트 입니다. 실제 로이필딩의 논문을 기반으로 상당히 자세하게 그리고 실무에 가깝게 풀어져 있었습니다. 물론 논문에 대한 해석은 모두 같을 수 없으며 다를 수 있습니다만 도움이 될것 같아서 들고왔습니다. 오늘은 여기서 본 내용중 Resource에 대한 내용을 정리해보도록 하겠습니다.

리소스(Resource)

REST API의 주요한 정보는 리소스라고 합니다. 여기서 말하는 리소스는 일반적으로 말하는 파일, 이미지 뿐만 아니라 우리가 일반적으로 교환하는 모든 정보를 포함합니다. 예를 들어 문서, 이미지, 일반적인 서비스, 리소스들의 집합, 객체 등이 될 수 있습니다.

그리고 특정 시점의 리소스의 상태를 리소스 표현(Resource Representation)이라고 부릅니다. 이런 리소스 표현에는 데이터, 메타데이터 그리고 상태를 변경할 수 있는 하이퍼링크가 포함됩니다.

데이터 타입은 ContentType 헤더에 media-type을 사용하여 나타냅니다.

예를 들자면 아래와 같은 형태 일것입니다.

get /devices http 1.1
ContentType: application/json // 메타데이터
Link: https://bad.example; rel="preload" // 하이퍼링크
{
    "data" :{ // 데이터
        ...
    }
}

리소스의 표현에서 다른 포맷과 다른 특별한 점은 하이퍼링크의 포함이라고 생각되집니다. 일반적으로 우리가 사용하고 하이퍼링크는 다른 사이트로의 이동을 원할때 사용하는 것이라고 알고 있었습니다. 하지만 로이필딩의 REST API에서는 다음과 같이 하이퍼링크를 말합니다.

Hypertext (or hypermedia) mean the simultaneous presentation of information and controls such that the information becomes the affordance through which the user (or automaton) obtains choices and selects actions. Remember that hypertext does not need to be HTML (or XML or JSON) on a browser. Machines can follow links when they understand the data format and relationship types.

즉 위 말에 따르면, 하이퍼텍스트는 유저가 선택적으로 정보의 표현과 제어를 동시에 할 수 있는 방법이라고 표현합니다. 여기서 주의할 점은 하이퍼텍스트가 HTML이나 XML, JSON을 이용한 방법으로 제한하는 것이 아니라 각 시스템에서 *이해할 수 있는 형식, 관계 타입을 갖추어 hypertext를 통한 link로 사용한다면 그것은 REST하다고 할 수 있다고 합니다.

요약

  • REST API의 Resource는 문서, 이미지, 서비스, 일반적 객체값 등을 포함.
  • 특정 시점의 Resource에 대한 상태(ex) 호출했을때 등 )를 Resource Representation이라고 함.
  • Resource Representation의 요소는 실제 데이터, 메타 데이터, 하이퍼링크(HATEOS)가 포함
  • 추가적으로 페이지를 가면 REST API는 self-descrive 해야한다. 즉,Client에서 Server로 가는 메시지 만으로도 쉽게 그 내용을 파악할 수 있어야 하는데 여기에 사용되어야 할 것이 custom media-types을 이용할 것을 권장하고 있습니다.

 

Resource Methods

또 하나의 REST의 중요한 요소는 Http Methods입니다. 많은 사람들이 resource methods를 GET/PUT/POST/DELETE와 관련있다라고 생각합니다. 사실, 로이필딩은 각 컨디션에 따라서 HTTP method를 맞춰사용해야 한다고 한적이 없고 uniform interface를 강조한 것이라고 합니다. 즉, 내가 custom media-types을 사용하고 있고 update에는 post를 사용한다고 기술해 두었다면 post를 사용하는게 RESTful한게 될 수 있습니다. (물론 일반적인 경우는 아닙니다.)

그래도 현재 우리는 일반적으로 HTTP를 사용할 때 아래와 같이 Http Methods의 이용을 정의하고 있습니다.

http method desc
get 읽기
post 쓰기
put 업데이트
patch 부분 업데이트
delete 삭제

기타사항

사실 REST는 HTTP가 필수적인 요소는 아니라고 합니다. 단지, HTTP가 REST를 구현하기 좀 더 쉽게 만들어 주고 있고, 우리는 웹어플리케이션 제작 = REST API 사용으로 보고 있습니다. 구현은 조금 귀찮더라도 일반 Appication에 REST API의 6원칙을 지킨다면 그 Application은 충분히 RESTful 하다라고 할 수 있습니다.

마무리

오늘은 REST API, 그 중에서도 Resource에 대해서 알아보았습니다. 다른 문서들에서 Resource를 중요시 여기면서도 Resource가 정확히 어떤 것을 의미하는지 서술하는 문서가 많지 않았습니다. 그러다 저도 이번에 정리하면서 여러 개념을 깨우칠 수 있었던 좋은 시간이 었습니다.

철학적인 내용이 오늘은 주를 이루었기 때문에 작성하면서 어려움이 많았습니다.. ㅠㅠ

다음번에는 조금 더 실무에 도움이 될 수 있는 Resouce의 naming에 대해서 중심적으로 알아보도록 하겠습니다.

감사합니다.

참조

https://restfulapi.net/

 

What is REST – Learn to create timeless REST APIs

 

restfulapi.net

https://www.iana.org/assignments/media-types/media-types.xhtml

 

Media Types

 

www.iana.org

 

반응형

댓글