REST는 Representational State Transfer라는 용어의 약자로서 2000년도에 로이 필딩 (Roy Fielding)의 박사학위 논문에서 최초로 소개되었다. 로이 필딩은 HTTP의 주요 저자 중 한 사람으로 그 당시 웹(HTTP) 설계의 우수성에 비해 제대로 사용되지 못하는 모습에 안타까워하며 웹의 장점을 최대한 활용할 수 있는 아키텍처로써 REST를 발표했다.
REST (Representational State Transfer) 란?
❓ 신입 개발자인 나는 REST의 정의부터 어려웠다 REST 라는 정의는 위에 작성한 것만 알면 충분할 것 같다
REST 필요한 이유?
- 애플리케이션 분리 및 통합
- 다양한 클라이언트 등장
- 최근의 서버프로그램은 다양한 브라우저와 모바일 디바이스에서도 통신할 수 있어야 함
그렇다면 REST API는 무엇일까?
쉽게 REST의 아키텍처 스타일을 따르는 것이 REST API다.
✔ REST 아키텍처 스타일
REST를 만든 로이 필딩은 5번 선택사항을 제외한 모든 조건에 만족하는 API만이 REST API라고 한다.
현재 우리가 알고있는 대부분의 REST API는 6번 통일된 인터페이스 조건을 만족하지 못한다.
Client-Server
- 클라이언트 – 서버가 서로 의존하지 않고 진화할 수 있게 분리
- 일관적인 인터페이스로 분리
Stateless (무상태)
- Client의 context를 Server에 저장하지 않는다, 즉 데이터를 주고 받는 것으로 끝 내야함
Cache
- 캐시 사용을 통해 트랜잭션이 발생하지 않기 때문에 전체 응답시간, 성능, 서버의 자원 이용률을 향상시킴
Layered System.
- 서버는 클라이언트 모르게 API 서버에 여러 계층을 추가하여 유연한 구조로 개발될 수 있게 계층형 시스템 구조가 되어야한다.
Code-On-Demand (Optional)
- Server로부터 스크립트를 받아서 Client에서 실행한다
Uniform Interface
- 전체적인 시스템 아키텍처를 간단하고 잘 파악할 수 있도록 하기 위한 약속된 Interface
Uniform Interface 제약조건
1. Identification of resources ( URI로 리소스가 식별)
2. Manipulation of resources through representations (representation 전송을 통해서 리소스를 조작)
3. Self-descriptive messages (메시지는 스스로 메시지에 대한 설명이 가능해야 함)
4. Hypermedia as the engine of application state (HATEOAS)
메시지만 잘 표현이 된다면 서버나 클라이언트가 변경되더라도 오고가는 메시지는 언제가 Self-descriptive 하므로 언제나 해석이 가능하다.
같은 팀내에서 개발을 진행한다고 가정했을때는 이정도의 메시지만으로 이 데이터의 응답이 무엇인지 정확히 알 수 있지만 소통이 어려운 상태에서는 위 메시지만으로는 정확한 해석이 어렵다.
그래서 대부분 Swagger나 별도의 API문서를 작성한다.
- Hypermedia as the engine of application state (HATEOAS)
애플리케이션의 상태는 하이퍼링크를 통해 전이되어야 한다라는 속성
특정 API를 요청한 뒤 클라이언트 입장에서 이 응답을 받은 다음 단계로 할 수 있는 작업(전이) 을 알려주는 것이며,
다음 단계 작업을 위한 리소스의 URI를 서버에서 제공하는 것
HTML 페이지 같은 경우는 a 태그를 통해 하이퍼링크를 제공하고 그 페이지에서 어떤 행위를 할 수 있는지를 나타내고 있지만 json 타입의 경우 표현하기가 애매하다.
사실 나는 HATEOAS의 필요성을 모르겠다.
이렇게 다음 작업을 알려주는 URI를 같이 넣어주면 API를 사용하는 사용자 입장에서는 매우 편리하겠지만
링크를 표현하는 방법을 직접 정의해야 하는 단점이 있으며 정확한 설계 원칙이 없기 때문에 표현하기 매우 애매하다.
끝으로
REST API를 공부하면서 느낀점은 API를 개발하고 구현하는데 REST는 크게 상관없는 단어라고 생각했다.
Rest를 따를 것인지는 API를 설계하는 이들이 스스로 판단하여 결정하고 정확한 표현과 규칙만 내부적으로 잘 정의해 놓
는다면 그게 진정으로 사용하기 쉬운 API가 아닐까라고 생각한다.
댓글