[REST API] REST API에 관하여_6가지 제약조건

안녕하세요. 한 달 전 정도에 REST API사용에 주의할 점이라는 주제로 Youtube를 본 것을 정리한 적이 있습니다. 이때의 아이디어를 떠올려 새로운 게시물을 연재해 볼까 합니다. 오늘의 주제는 REST API의 6가지 제약조건입니다.

이전 포스팅에서 REST API는 REST 아키텍처를 따르는 시스템이라고 했습니다. 그리고 그 구성요소로는 아래와 같다고 했었습니다.

• Client-Server
• Stateless
• cache
• uniform interface
• layered system
• code-on-demand

이때는 Uniform Interface에 대해서 중심적으로 설명드렸습니다.

이번에는 전체적으로 한번 짚고 넘어가 보려고 합니다.

잘부탁드리겠습니다.

---

개요

REST는 Representational State Transfer의 약자로 해당 용어는 로이필딩에 의해 만들어졌습니다. REST라는 것은 웹 서비스에서 많이 사용되는데 Application 사이에 결합도를 낮추게끔 설계하는 아키텍처 스타일입니다. 결합도를 낮춰 서버 / 클라이언트가 별도로 구축되고 결합될 수 있게 하는 것이지요.

아키텍처적인 결합도를 낮추기 위해 REST는 위에 언급한 6가지의 제약조건을 가지고 있습니다. 이러한 제약조건을 잘 지킨다면 이 시스템은 RESTful한 시스템이 되는 것이지요.

오늘은 이 각각에 대해서 한번 간략하게 알아보는 시간을 가지도록 하겠습니다.

Client-Server

• 사용자들에게 제공하는 interface인 User Interface와 데이터 스토리지, 알고리즘 등 서버 내부의 작업들을 분리함으로 써 User Interface는 여러 플랫폼에서의 이식성을 향상될 수 있으며, 서버는 그 구성요소를 단순화하여 확장성을 단순화할 수 있습니다.
• 클라이언트와 서버가 서로 의존하지 않고 별도로 진화할 수 있습니다. 클라이언트는 서버의 리소스 URI만 알고 있으면 되기 때문입니다.

Stateless

• 클라이언트에서 서버로의 각 요청에는 그 요청을 이해하는 데 필요한 모든 정보가 포함되어야 합니다. 서버에 저장된 환경 정보를 이용해서 이득[서버에서의 클라이언트 정보 유지 등]을 취하면 안 됩니다. 따라서 세션의 정보는 전적으로 클라이언트가 가지고 있어야 합니다.
• 로그인했다는 세션 유지가 필요하다면 그 정보 또한 Client가 해당 정보를 가지고 서버에 전달해야 한다. [ex) JWT 등을 사용]

Cacheable

• 요청에 대한 응답 내의 데이터에 해당 요청은 캐시가 가능한지 불가능 한지 명시해야 합니다. 응답을 캐시 할 수 있다면 클라이언트에서 동일한 요청이 왔을 때 응답 데이터를 재사용할 수 있어야 합니다.
• cache-control 헤더를 통하여 캐시 여부 명시

Uniform Interface

• 전체적인 시스템 아키텍처를 간단하고 잘 파악할 수 있도록 하기 위한 약속된 Interface, 해당 규약을 REST를 사용자들이 지킴으로써 추후에 사용하는 Client를 개발하는 사용자와 Server를 개발하는 사용자 간의 결합도가 낮아질 수 있다(Decoupling). 개발 REST는 규약으로 4가지를 제시합니다.
  • identification of resources
  • manipulation of resources through representations
  • self-descriptive messages
  • hypermedia as the engine of application state.

이 규약에 관해서는 이전 포스팅에서 다룬 적이 있습니다.

Layered System

• 계층화된 시스템 아키텍처를 사용하여 각 구성들 간의 계층을 마음대로 상호작용 할 수 없도록 제한 함으로 써 Interface를 일원화할 수 있습니다.

Code on demand (optional)

• 서버가 네트워크를 통해 클라이언트에 전달한 javascript 등과 같은 프로그램들은 그 자체로 실행이 될 수 있어야 한다. 이것은 사전 구현에 필요한 기능의 수를 줄임으로써 클라이언트를 단순화합니다.
• 이 말은 우리가 평소에는 정적인 데이터를 xml 또는 json에 담아서 client로 보내고 client가 이것을 가공합니다. 하지만 code on demand라는 것은 client에 보내는 데이터를 바로 실행 가능한 코드를 보내서 이것을 Client에서 실행하는 것을 말합니다.

마무리

이렇게 해서 REST API의 6가지 규약에 대해서 알아보았습니다.

나름 딱딱하지 않게 잘 풀어내려고 노력했는데 어떠셨을지 모르겠습니다.

REST API는 이러한 규약을 준수하기 위해 Resource에 대해서 중요하게 언급했습니다. 다음 시간에는 REST API의 Resource에 대해 알아보도록 하겠습니다.

감사합니다.

참조

https://restfulapi.net

What is REST – Learn to create timeless REST APIs