나중에도 봐야겠지?

2024.05.10 (금) REST API

혹시나도? 2024. 5. 10. 19:13

REST(REpresentational State Transfer)

이름처럼 상태의 전이(State Transfer)를 표현하기 위한 HTTP 상의 아키텍처 스타일
여기서 State는 Resource의 State를 표현하며, 이 Resource는 파일, 문서, 데이터 등을 모두 포함한다.
우리는 데이터를 응답해 주는 역할을 하고, 이 데이터는 위에서 우리가 정의한 Domain Model에 대한 데이터이기 때문에,
Resource가 Domain Model을 칭한다고 보셔도 무방하다

 

  • URI(Resource) - 먼저 URI를 통해 Reousrce 이름을 표현한다
  • Method(Verb) - HTTP의 Method를 사용해 상태를 변경하는 행위(Verb)를 표현한다. HTTP Method는 GET, POST, PUT, PATCH, DELETE, OPTIONS로 구성된다.
    • GET : Read 요청. Resource의 정보를 획득하기 위해 사용
    • POST : Create 요청. 새로운 Resource를 생성하기 위해 사용
    • PUT : Update 요청. Resource에 대한 정보를 수정하기 위해 사용. 수정되는 정보를 포함한 모든 Resource의 정보를 포함하여 요청
    • PATCH : Update 요청. Resource에 대한 정보를 수정하기 위해 사용. 수정되는 정보만을 요청
    • DELETE : Delete 요청. Resource를 삭제하기 위해 사용
    • OPTIONS : 서버와 클라이언트 사이의 통신 옵션을 확인하기 위해 사용. REST에서 표현을 위해 사용하진 않고, HTTP에서 보안 및 효율성을 위해 자동적으로 생성되는 요청
  • SON, XML 등(Representation of Resource) - Resource의 상태를 표현하는 방법이다. 어떤 형태의 데이터 구조를 사용해도 무방

REST API와 RESTful API의 차이점

RESTful 하다. 즉, REST의 규칙을 아주 잘 지킨다는 말이다

사실, 위에서 설명한 REST는 REST 규칙을 모두 담고 있진 않는다.

Leonard Richardson은 REST API를 잘 적용하기 위해 아래와 같이 성숙도 모델(Maturity Model)을 정의했다

 

  • Level 0: The Swamp of POX
    • 소수의 URI를 갖고 있고, 일반적으로 POST만을 사용하는 스타일. RPC(Remote Procedure Call) 스타일과 유사
  • Level 1: Resources
    • 위에서 설명한 REST와 유사하게 URI를 통해 Resource를 표현. 하지만, Verb (HTTP Method)를 POST만 주로 사용
  • Level 2: HTTP Verbs
    • 바로 우리가 이해한 REST이다. Resource를 URI로 사용하면서, HTTP Method를 통해 행위(Verb)에 대해서도 표현하고 있다
  • Level 3: Hypermedia Controls
    • Level 2에 더하여 HATEOS(Hypertext As The Engine Of Application State)를 잘 지킨 단계라고 볼 수 있다
    • 클라이언트에게 응답을 할 시 다음 단계로 할 수 있는 작업에 대해 알려주기도 한다
    • 즉, Resource에 대한 데이터만 응답하는 것이 아니라, 클라이언트의 다음 작업을 위한 URL 도 함께 알려준다