• Restful?
  REST 원칙을 적용하여 서비스 API를 설계한 것.

• API?
  기존에 있는 응용 프로그램을 통해서 데이터를 제공받거나 기능을 사용하고자 할 때 사용하는 인터페이스 및 규격.

1. REST

Representational State Transfer. 네트워크 자원을 정의하고 처리하는 방법 전반을 일컫는 개념. 기존에 존재하던 HTTP의 장점을 최대한 활용할 수 있는 방법을 포함한다.

자원을 이름으로 구분하여 해당 자원의 상태를 주고받는 모든 것. HTTP URI를 통해 자원을 명시하고 HTTP 메서드(POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD를 적용하는 것을 뜻한다.

2. REST, HTTP, RESTful

HTTP를 최대한 잘 활용할 수 있도록 개발된 개념이 REST 원칙. 그리고 이 REST 원칙을 준수하여 만든 API를 RESTful API라고 부른다.

간단하게 설명하자면 HTTP API에 여러가지 제약 조건이 추가한 것이 바로 REST.

3. REST의 6대 원칙

인터페이스 일관성

서로 다른 컴포넌트 간의 통신을 단순화하고 표준화하기 위해 인터페이스가 일관되어야 한다.

인터페이스 일관성 아래에는 4개 제약조건을 포함하는데, 이 부분은 뒤에서 다루고 있다.

무상태성 (Stateless)

서버는 각 요청을 독립적으로 처리하며, 클라이언트의 상태 정보를 서버에 저장하지 않는다. 모든 클라이언트의 필요한 정보는 요청 자체에 포함되어야 하며, 서버의 부하 분산과 확장성을 개선한다.

캐시 처리 가능성(Cacheable)

응답 데이터는 캐싱을 허용하는 방식으로 설계되어야 한다. 클라이언트나 중간 서버는 응답 데이터를 캐시하고 필요한 경우 서버로부터 다시 가져올 수 있다. 이로써 성능과 응답 시간을 개선할 수 있다.

계층화(Layered System)

서버와 클라이언트 사이에 여러 계층을 두어 중간 서버(프록시, 캐시 등)를 사용할 수 있도록 한다. 보안, 로드 밸런싱, 캐싱 등의 기능을 쉽게 추가하거나 변경할 수 있다.

Code on demand

필요한 경우 서버가 클라이언트에게 코드를 전송하여 실행할 수 있는 기능을 제공할 수 있다.

클라이언트/서버 구조

클라이언트와 서버는 독립적으로 개발되어야 하며, 서로의 변경 없이 독립적으로 발전할 수 있어야한다. 이를 통해 시스템의 확장성과 유연성을 개선할 수 있다.

4. REST 인터페이스 일관성의 4대 제약 조건

자원의 식별

고유한 URI 식별자: 각 리소스는 고유한 식별자인 URI(Uniform Resource Identifier)를 가진다. URI는 클라이언트가 리소스를 찾아가기 위한 주소 역할을 한다. 예를 들어, /users/123과 같은 URI는 사용자 리소스를 식별한다.

명사를 사용한 식별: 리소스는 명사로 표현되며, 동사나 동작이 아닌 실제 개념을 나타내는 것이 중요하다. 이렇게 하면 의미가 더 명확해지고 직관적으로 이해할 수 있다.

리소스의 계층 구조: URI는 계층적인 구조를 가질 수 있다. 이 계층 구조를 이용하여 리소스 간의 관계를 표현하고 다룰 수 있다. 예를 들어, /users/123/orders는 사용자 123의 주문 목록 리소스를 나타낸다.

HTTP 메서드 활용: 클라이언트는 HTTP 메서드(GET, POST, PUT, DELETE 등)를 사용하여 리소스에 접근하고 조작한다. 각 메서드는 리소스에 수행할 동작을 나타낸다. 예를 들어, GET은 리소스 조회, POST는 리소스 생성, PUT은 리소스 업데이트, DELETE는 리소스 삭제 등을 의미한다.

메시지를 통한 리소스 조작

• 메시지?
  리소스의 상태를 나타내는 데이터. 이 데이터를 통해 리소스를 생성, 조회, 수정, 삭제해야 한다.

자기서술적 메서지

각 요청과 응답이 자체적으로 명확하고 이해하기 쉬운 메시지를 가져야 한다는 개념을 가져야 한다.

클라이언트의 요청은 명확하게 어떤 동작을 수행하려는지 전달해야 합니다. 이를 위해 HTTP 메서드, 헤더, URI 및 데이터 페이로드(본문) 등의 정보가 명시되어야 한다.

서버의 응답은 자체적으로 어떤 결과를 나타내는지 명확하게 전달되어야 한다. 응답의 상태 코드, 헤더, 데이터 페이로드 등이 이 정보를 제공한다.

애플리케이션의 상태에 대한 엔진으로서 하이퍼미디어

응답 데이터에는 클라이언트가 다음에 수행할 수 있는 동작에 대한 링크가 포함되어야 한다.

• 애플리케이션의 상태에 대한 엔진으로서 하이퍼미디어 원칙을 구현하기 어려운 이유.

  여러가지가 있지만 대표적으로 구현하기 어려운 부분이 마지막에 있는 부분인데요. 이것은 HTML처럼 하이퍼링크가 추가되어서 다음에 어떤 API를 호출해야 하는지를 해당 링크를 통해서 받을 수 있어야 합니다.

  출처 : HTTP API vs REST API, 지식공유자 김영한의 답변

  하이퍼미디어 링크를 지원하기 위해서는 API 응답 데이터에 링크 정보를 포함해야 합니다. 이러한 링크는 클라이언트가 수행할 수 있는 모든 동작을 표현해야 하는데, 이는 복잡한 데이터 구조와 링크 관리를 필요로 합니다.

  클라이언트는 서버에서 받은 링크를 해석하고 적절한 동작을 수행해야 합니다. 이로 인해 클라이언트 코드에 복잡성이 추가되고, API를 사용하는 개발자들이 링크 구조를 이해하고 활용하는 데 노력이 필요합니다.