나중에도 봐야겠지?
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 도 함께 알려준다