이 글은 restfulapi.net을 개인적인 학습을 위해 번역한 포스트입니다.
잘못된 내용이 있다면 말씀 부탁 드립니다.

REST란 무엇인가

REST는 REpresentational State Transfer의 두문자어(낱말의 머리글자를 모아서 만든 준말)이며 분산 하이퍼미디어 시스템의 아키텍처 스타일입니다.
Roy Fielding은 2000년 그의 유명한 논문에서 이를 처음 발표했습니다.

다른 아키텍처 스타일과 마찬가지로, REST에는 기본 원칙과 제약 조건이 있습니다. 서비스 인터페이스를 RESTful이라고 해야 하는 경우 이러한 원칙을 충족해야 합니다.

REST 아키텍처 스타일을 준수하는 Web API(또는 웹 서비스)는 REST API입니다.

1. REST의 기본 원칙

Restful 아키텍처의 6가지 기본 원칙 또는 제약 조건은 다음과 같습니다.

1.1. 균일한 인터페이스 (Uniform Interface)

구성요소 인터페이스에 일반성의 원칙을 적용하여 전체 시스템 아키텍처를 단순화하고 상호작용의 가시성을 개선할 수 있습니다.

여러 아키텍처 제약 조건은 균일한 인터페이스를 확보하고 구성 요소의 동작을 안내하는 데 도움이 됩니다.

다음 네 가지 제약 조건은 균일한 REST 인터페이스를 달성할 수 있습니다.

• 리소스 식별 - 인터페이스는 클라이언트와 서버간의 상호작용과 관련된 각 리소스를 고유하게 식별해야 합니다.

• 표현을 통한 리소스 조작 - 리소스는 서버 응답에서 균일한 표현을 가져야 합니다. API 사용자는 이러한 표현을 사용하여 서버의 리소스 상태를 변경해야 합니다.

• 자체 설명 메시지 - 각 리소스 표현에는 메시지 처리 방법을 설명하기에 충분한 정보가 포함되어야 합니다. 또한 클라이언트가 리소스에 대해 수행할 수 있는 추가 작업에 대한 정보도 제공해야 합니다.

• 애플리케이션 상태의 엔진으로서의 하이퍼미디어 - 클라이언트는 애플리케이션의 초기 URI만 가져야 합니다. 클라이언트 애플리케이션은 하이퍼링크를 사용하여 다른 모든 리소스와 상호 작용을 동적으로 구동해야 합니다.

1.2. 클라이언트-서버 (Client-Server)

클라이언트-서버 디자인 패턴은 관심사를 분리하여 클라이언트와 서버 구성요소가 독립적으로 발전하는 데 도움을 줍니다.

사용자 인터페이스 관심사(Client)와 데이터 스토리지 관심사(Server)를 분리하여 여러 플랫폼에서 사용자 인터페이스의 이식성을 개선하고 서버 구성 요소를 단순화하여 확장성을 개선합니다.

클라이언트와 서버가 진화하는 동안 클라이언트와 서버 간의 인터페이스/계약이 깨지지 않도록 해야 합니다.

1.3. 무상태 (Stateless)

무상태는 클라이언트에서 서버로 보내는 각 요청에 요청을 이해하고 완료하는 데 필요한 모든 정보를 포함해야 합니다.

서버는 서버에 이전에 저장된 컨텍스트 정보를 이용할 수 없습니다.

이러한 이유로 클라이언트 애플리케이션은 세션 상태를 완전히 유지해야 합니다.

1.4. 캐시 가능 (Cacheable)

캐시 가능 제약 조건에서는 응답이 암시적 또는 명시적으로 캐시 가능 또는 캐시 불가능으로 스스로 레이블을 지정해야 합니다.

응답이 캐시 가능한 경우 클라이언트 애플리케이션은 지정된 기간동안의 동등한 요청에 대해 나중에 응답 데이터를 재사용할 수 있는 권한을 얻습니다.

1.5. 계층화된 시스템 (Layered System)

계층화된 시스템 스타일을 사용하면 구성 요소 동작을 제한하여 아키텍처가 계층적 레이어로 구성될 수 있습니다.

예를 들어, 계층화된 시스템에서 각 구성요소는 상호 작용하는 계층 너머를 볼 수 없습니다.

1.6. 주문형 코드 (Code on Demand) - Optional

REST는 또한 애플릿 또는 스크립트 형태의 코드를 다운로드하고 실행하여 클라이언트 기능을 확장할 수 있도록 합니다.

다운로드한 코드는 미리 구현해야 하는 기능의 수를 줄여 클라이언트를 단순화합니다.
서버는 클라이언트에게 전달되는 기능의 일부를 코드 형태로 제공할 수 있으며 클라이언트는 코드를 실행하기만 하면 됩니다.

2. 리소스란 무엇인가?

추가 예정

3. 리소스 메서드

추가 예정

4. REST와 HTTP는 같지 않다.

추가 예정

5. 요약

추가 예정