[WEB] REST & REST API

REST(Representational State Transfer)

논문: https://ics.uci.edu/~fielding/pubs/dissertation/top.htm

REST는 네트워크 환경에서 통신을 관리하기 위한 설계 지침을 의미한다. 이때, REST의 모든 제약조건을 지켜야 한다는 의미가 아니라, 지키면 네트워크 통신을 설계하기 유리하다는 측면으로 바라보는 것이 좋다.

REST를 만족하는 아키텍처는 다음과 같은 제약조건을 따라야 한다.

1. Client - Server
2. Stateless
3. Cache
4. Uniform Interface
5. Layered System
6. Code On Demand

Client - Server

클라이언트와 서버로 분리되어야 하며, 둘은 의존성이 없어야 한다. 관심사 분리를 통해 각 구성요소를 독립적으로 개발할 수 있다는 것이 장점이며, 확장성을 높이기 위해 서버 측은 단순해야 한다.

Stateless

상태 정보를 따로 저장하지 않는다. 클라이언트 요청은 서버가 요청을 이해하고 처리하기 위해 필요한 모든 정보를 포함해야 한다. 서버 측 상태, 즉 세션이 유지되지 않는다면 요청을 처리하는 동안 서버를 자유롭게 교체할 수 있으므로 의존성이 감소하고 로드밸런싱 등 탄력성이 높아진다.

논문에서는 서버 측 세션을 권장하지 않는다. 하지만, 보안 등 측면에서는 세션을 완전히 배제하기는 어렵다. 가능하면 무상태를 추구하되, 보안 등의 측면에서 세션이 필요하면 사용해야 한다.

Cache

통신 간 캐싱 기능을 적용해야 한다. 캐시 기능을 추가하면 클라이언트 - 서버 통신 도중 일부 요청 및 응답을 제거할 수 있어 통신에 필요한 시간이 감소하므로 효율성, 확장성 및 사용자 경험이 좋아진다.

Uniform Interface

데이터를 표준화된 형식으로 전송하기 위한 통합 인터페이스를 제공해야 한다. 균일한 인터페이스를 사용하면 일관된 방식으로 상호작용을 정의하기 때문에 이를 이해하기 쉽고, 단순해진다.

제약조건에는 4가지가 있다. 거의 대부분의 경우 REST 지침은 HTTP 프로토콜과 함께 사용되므로, 제약 조건도 HTTP 프로토콜을 기준으로 설명해보자.

1. identification of resources: URI를 이용하여 각각의 자원을 식별한다
2. manipulation of resources through representation: HTTP 메서드를 이용하여 자원에 대한 조작을 표현한다.
3. self-descriptive messages: 메시지만 보고도 뜻을 파악할 수 있어야 한다. 이를 위해  요청 및 응답은 메시지에 대한 메타 데이터(데이터 타입, 호스트 등)를 함께 제공해야 한다.
4. hypermedia as the engine of application state(HATEOAS): 서버는 클라이언트가 리소스를 조작할 수 있도록 메시지에 하이퍼미디어 링크를 포함해야 한다. 좀 더 구체적으로는 자원을 응답할 때, "save" 나 "delete" 처럼 자원에 적용할 수 있는 API 정보를 본문에 추가적으로 제공한다.

HATEOAS

하이퍼미디어는 멀티 미디어(텍스트, 이미지, 영상 등)를 하이퍼 링크를 통해 이동할 수 있는 비선형 구조를 의미한다.

HATEOAS는 직역하면 "어플리케이션 상태 엔진으로서의 하이퍼미디어"이다. 상태 엔진을 state machine으로 해석하면, 애플리케이션의 상태를 전이(조작)하는데 하이퍼 미디어를 이용해야 한다는 의미가 된다.

{
  "id": 123,
  "name": "John Doe",
  "age": 30,
  "links": [
    {
      "rel": "self",
      "href": "https://api.example.com/users/123"
    },
    {
      "rel": "update",
      "href": "https://api.example.com/users/123",
      "method": "PUT"
    },
    {
      "rel": "delete",
      "href": "https://api.example.com/users/123",
      "method": "DELETE"
    }
  ]
}

HATEOAS를 만족하는 경우, 응답에 자원의 상태를 조작하기 위한 API 링크를 포함해야 한다. 사용자는 본문에 포함된 링크를 이용하여 쉽게 자원의 상태를 변경할 수 있다. 응답 메시지만으로도 이 자원을 조작할 방법을 알 수 있는 셈이다.

 Layered System

시스템은 여러 계층으로 구성될 수 있으며, 각 계층은 독립적으로 발전할 수 있다. 계층 구조를 통해 서비스 구현을 캡슐화하거나, 로드밸런싱 등을 추가하여 시스템 확장성을 높일 수 있다.

Code On Demand(선택적)

스크립트 형식으로 코드를 보내 클라이언트 기능을 확장할 수 있다.

 위 제약 조건들은 최근 웹 개발 트렌드를 고려하면 당연한 이야기들이다. 클라이언트는 간단한 인터페이스로 기술을 이용하되, 서버는 계층적으로 구성될 수 있다. 로드 밸런싱 등 서버 확장을 위해 서버 측 대신 클라이언트 측에서 상태 정보를 관리하는 편이 좋으며, 캐싱 기능을 추가하여 응답 대기 시간을 줄여야 한다...

 반대로 생각하면 지금 당연하다고 생각하는 것들이 과거에는 당연하지 않았으며, 현재 웹 개발에서의 마음가짐은 이러한 다양한 제안과 발전에 따른 결과물이라고 생각할 수 있겠다.

REST 구성 요소

REST는 사용해야 할 프로토콜을 명시하지 않는다. 하지만 현실적으로 RESTful API는 HTTP 프로토콜과 연관되는데, 네트워크 통신의 대부분을 차지하는 웹 관련 통신에 HTTP 프로토콜이 사용되기 때문이다.

• 자원(Resource): URI를 이용하여 자원을 구분한다.
• 행위(Verb): HTTP 메서드를 통해 동작을 구분한다.
• 표현(Representation): JSON, XML 등 적합한 형식을 선택 + Content-Type으로 명시한다.

REST API

자원은 URI로, 자원에 대한 행위는 HTTP 메서드로 표현하는 API 설계 방식을 의미한다. 현존하는 대부분의 서비스는 REST 설계 원칙을 어떻게든 따르고 있기 때문에, RESTful API는 REST를 기반으로 한다.RESTful API는 다음과 같은 특징을 따른다.

1. URI를 통해 자원을 표현한다.
2. 자원에 대한 행위는 HTTP Method를 통해 표현한다.

가장 자주 하는 실수는 URI에 자원에 대한 동작을 포함하는 것이다.

부적절한 사용법	적절한 사용법
GET /employeeList	GET /employees
	GET /employees/{id}
POST /updateEmployee	PUT /employees/{id}
POST /addEmployee	POST /employees
POST /deleteEmployee/{id}	DELETE /employee/{id}

URI는 자원을 표현하는 목적으로 사용되어야 하지, 자원에 대한 행위를 표현하는 데 사용되어서는 안 된다. 행위는 HTTP Method를 이용하여 표현해야 한다.