[Network] REST API란?

REST API

REST(Representational State Transfer) API는 데이터 또는 리소스를 HTTP 프로토콜을 통해 URI로 요청하고 응답받는 방식을 의미합니다. API의 역할은 클라이언트와 서버 모두 올바르게 사용할 수 있어야 합니다. 따라서, 올바르게 사용할 수 있는 규칙들을 정의하여 디자인하는 것은 중요한 작업입니다.

Richardson Maturity Model 정리

Richardson Maturity Model에 따르면 REST API를 실용적으로 적용하기위한 0단계에서 3단계로 성숙도 모델을 정의했습니다.

0단계 - 기본 단계

0단계에서는 REST API를 사용하지 않고 단순히 HTTP Protocol을 사용하는 기본 단계입니다. 실용적인 REST API를 만들기 위한 기본 단계라고 할 수 있습니다.

1단계 - 개별 리소스와 통신 준수

1단계는 개별 리소스와 통신을 준수하는 단계입니다. 모든 리소스는 각 리소스에 맞는 Endpoint를 사용하여 요청하고 자원에 대한 정보를 응답해야 합니다.

2단계 - HTTP 메소드 준수

2단계는 HTTP 메소드의 사용에 중점을 둔 단계입니다. CRUD에 따른 적절한 메소드를 사용해야 합니다. 또한, HTTP 메소드 사용에도 규칙(MDN HTTP Request Methods)을 따릅니다.

1. GET 메소드는 서버의 데이터를 변경하지 않는다.
2. POST는 요청마다 새로운 리소스를 생성한다.
3. PUT은 요청마다 같은 리소스를 반환하는 멱등성(idempotent)을 가진다.
4. PUT은 교체, PATCH는 수정의 용도로 사용한다.

3단계 - HATEOAS 적용

마지막 단계인 3단계는 HATEOAS(Hypertext As The Engine Of Application State)을 적용하는 단계입니다. HATEOAS는 Hypertext를 통해 애플리케이션의 상태 전이가 가능해야하는 REST 애플리케이션 아키텍처의 제약입니다. 응답 메세지에 리소스의 URI 포함하는데, 이는 효율적으로 리소스와 기능에 접근 가능한 트리거가 될 수 있습니다.

REST API의 6가지 제약조건(Constraints)

• Client-server
  • 리소스가 있는 쪽을 서버, 리소스를 요청하는 쪽을 클라이언트로 정의
• Stateless
  • 서버는 클라이언트의 Context를 저장하지 않고, 각각의 요청에 대해 별개로 인식하고 처리
• Cacheable
  • 대량의 요청을 효율적으로 처리
• Layered System
  • 클라이언트는 REST API 서버만을 호출
  • 서버는 보안, 로드 밸런싱, 암호화, Proxy 등 다중 계층으로 구성
• Code on Demand(옵션)
  • 규칙 중에 유일하게 옵션으로 API의 응답을 확인해볼 수 있는 UI 위젯을 제공
• Uniform Interface - 리소스에 대한 요청을 통일되고, 한정적으로 수행하는 아키텍처 스타일
  • Identification of Resources
    • 리소스가 URI로 식별되면 된다.
  • Manipulation of Resources through Representations
    • 리소스를 추가, 수정, 삭제 등의 행위를 HTTP Message에 표현을 포함시켜야 한다.
  • Self-Descriptive Messages
    • 메세지를 스스로 설명해야한다.
    • Description, Content-Type 등
  • Hypermedia As The Engine Of Application State (HATEOAS)
    • 애플리케이션의 상태는 Hyperlink를 이용해 전이되어야 한다.
  올바른 REST API를 사용하기 위해서는 6가지의 제약조건을 갖춰야 합니다. HTTP API의 사용만으로 Client-Server, Stateless, Cacheable, Layered System, Code on Demand(옵션)는 지켜집니다. 그러나, Uniform Interface를 지키기가 어렵습니다. 그 중에서도 Self-Descriptive Messages, HATEOAS는 잘 지켜지지 않고 있습니다.

왜? Uniform Interface 의 제약조건을 지켜야할까요?

서버와 클라이언트가 있을 때, 독립적인 진화가 가능해집니다. 서버가 여러 업데이트를 진행해도 클라이언트는 업데이트를 할 필요가 없는 것입니다. REST API의 설계 목적가 가장 인접하다고 할 수 있습니다. 예를 들어, 출시한지 얼마안된 모바일 앱의 서버를 지속적으로 최적화하면서 모바일 앱도 업데이트를 요구합니다. 이 경우 사용자는 이용 중 많은 불편함을 느끼게 될 수 있습니다. 즉, 독립적인 진화가 필요합니다. REST API의 설계자인 로이 필딩은 HTTP API를 고치면 앱에 문제가 생기는 부분을 고민했고, Uniform Interface를 만족해야만 REST API라고 말할 수 있게 되었습니다.

REST API의 제약 조건 중 하나라도 빠지도 REST API인가? NO

REST API를 사용해봤다면 한 가지 의문점이 생깁니다. ‘REST API의 제약 조건을 모두 지키지 않지만 잘 동작합니다. 꼭 다 지켜야 REST API인가요? 잘 동작하면 되는거 아닌가요?’라고 이야기할 수 있습니다. 로이 필딩은 단호하게 REST의 모든 제약조건을 지키지 않는다면 REST API가 아니라고 이야기합니다. 추가적으로 전체 시스템을 통제할 수 있거나, 독립적인 진화에 관심이 없다면 REST의 모든 제약조건을 고민하지 말라고 이야기합니다. 즉, REST 제약조건을 모두 따르지 않다면 REST API가 아니지만 HTTP API라고 할 수 있는 것입니다. 로이 필딩은 REST의 제약조건을 모두 따르지 않는다면 다른 단어를 써달라고 이야기했습니다. 결국, 단어 선택의 차이일 뿐 사용에 문제가 없다면 HTTP API라고 말하면 되는거 아닐까요?🤣