Rest api 기본 정리 - Ohjongsung's Dev Story

REST API 에 관한 이론적인 내용을 체계적으로 하나둘씩 정리해보려고 한다. 이 글에선 REST API 의 기본적인 내용에 대해서 정리하겠다.

API

“defined methods of communication between various software components”

REST

“REST는 Representational State Transfer의 줄임말로, 웹을 위한 네트워크 기반 아키텍처 스타일이다. REST는 Roy T. Fielding이 그의 박사학위 논문 “Architectural Styles and the Design of Network-based Software Architectures” 에서 처음 소개하였다.”

REST 구성요소

Resource 자원을 식별하는 URI Verb 자원에 대한 행위를 뜻하는 HTTP method Representations 자원을 표현하는 메시지 “매장 ID 가 1인 매장 정보를 조회한다.” 를 REST API 형태로 표현하면,

HTTP GET  https://shops/1

{  
   "shops":{  
      "id":"1"
      "name":"nike"
   }
}

REST 제약조건

Client-Server

관심사 분리 법칙에 따라 User Interface에 대한 관심과 데이터 저장에 대한 관심사를 분리한다. 다양한 플랫폼에서 User Interface 의 이식성을 향상시키고, 서버 구성요소를 단순화해서 확장성을 증대한다.

Stateless

클라이언트와 서버의 통신은 무상태여야 한다. 따라서 클라이언트의 요청은 서버에게 필요한 모든 정보가 담겨있어야 하며, 서버에 컨텍스트(클라이언트 정보 같은)를 저장해서 활용해서는 안된다. 무상태 제약 조건에는 가시성, 신뢰성, 확장성도 포함된다. 하나의 요청에 필요한 모든 정보가 있으니, 가시성이 좋아진다. 부분적으로 장애가 발생해도 잃어버린 상태값이 없으니 다시 요청하면 되므로 신뢰성도 향상된다. 마찬가지로 요청간의 상태를 저장하지 않으니 확장성이 개선되어 서버 자원의 추가 및 구현이 간단해진다.

Cache

캐시가 가능해야한다. 모든 서버 응답은 캐시 가능한지 그렇지 아닌지 알 수 있어야한다. 캐시를 추가하면 응답 대기 시간을 줄임으로써 효율성, 확장성 및 사용자 입장에서 성능 향상을 느낄 수 있다.

Uniform Interface

클라이언트, 서버 등 구성요소 간의 인터페이스는 균일(Uniform) 해야한다. 정리하면, REST API 는 기본 URI 와 미디어 타입의 정의만 알면 이용할 수 있어야 한다.

Uniform Interface 제약 조건

identification of resources 클라이언트는 리소스마다 가지고 있는 고유한 URI 식별자를 서버에 전달해서 서버는 클라이언트가 해석할 수 있게 리소스를 구성해서 반환한다. 서버가 리소스를 구성하는 방법은 클라이언트에게 중요하지 않다. manipulation of resources through representation RESTful 응용 프로그램은 동일한 URI에서 동일한 자원의 표현을 둘 이상 지원할 수 있다. 식별된 리소스는 클라이언트가 서버에 전달한 Accept HTTP 헤더를 통해 HTML, XML, SVG, JSON 등과 같은 다양한 표현으로 반환 될 수 있다. 또한, Content-Type HTTP 헤더를 통해 서버에 보내는 데이터의 표현을 나타낼 수 있다. 즉, 해당 자원을 식별하는 URI에서 자원 표현을 분리한 것이다. self-descriptive messages 요청이나 응답 메시지에는 이를 이해하기 위한 모든 정보가 포함되어야 한다. 쉽게 말하면, API 메시지 자체만 보고도 API를 이해할 수 있는 구조를 가져야 한다는 것이다. URI 와 HTTP method 그리고 응답 메시지를 통해서 쉽게 API를 파악할 수 있게 해야 한다. hypertext as the engine of application state HTTP Response에 다음 Action이나 관계되는 리소스의 상태 변경을 위한 Action 을 Hypertext Link 형태로 제공한다. 쉽게 말해서 우리가 웹 사이트에 접속하면, 웹 사이트는 웹 사이트 내에서 이동 가능한 Hypertext Link 를 제공한다. 이것을 API 에서도 동일하게 적용하는 것을 말한다. 줄여서 HATEOAS 라고도 한다. REST APIs must be hypertext driven 라고 Roy Thomas Fielding 이 말했는데, 이걸 제공해주는 API가 정말 있나?

Layered System

계층(hierarchical layers)으로 구성이 가능해야한다. 보안, 로드 밸런싱, API 게이트웨이와 같은 계층을 추가해서 전체 시스템의 복잡성을 분리하고 각 계층에 대한 독립성과 유연성을 확보한다. 단, 서버와 클라이언트 간의 상호작용은 일관성있어야 한다. 정리하면, 클라이언트는 여전히 REST API 서버를 호출하는 것이지만, 서버는 여러 계층으로 구성되어 로드 밸런싱, 보안, API 게이트웨이 추가해서 구조의 독립성과 유연성을 확보한다.

Code-On-Demand

REST는 애플릿이나 스크립트 형식으로 코드를 다운로드하고 실행하여 클라이언트 기능을 확장 할 수 있도록한다. 그러나 이는 가시성을 감소 시키므로 필수 제약조건이 아니다.

Reference

http://haah.kr/2017/05/24/rest-the-dissertation-summary/
http://exyus.com/articles/rest-the-short-version/
https://blog.npcode.com/author/yieungjun/
https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm