https://aws.amazon.com/ko/what-is/restful-api/

REST란

• REST(Representational State Transfer)는 API의 개발 구조나 스타일에 대해 정의한 내용이다.

  • 예를들어 서버에 데이터를 요청할때 우리가 HTTP를 사용하여 URL이라는 state로 JSON(또는 HTML / XML등 클라이언트가 사용할 수 있는)이라는 형태의 Representation을 가진 데이터를 요청할때, 이런게 RESTful API라고 할 수 있다.

    

Six REST Architectural Constraints

REST

진정한 REST가 되려면 로이 필딩이 그의 박사 논문에서 제안한 다음 6가지 제약 조건을 만족해야 한다고 한다.

1. Client-server architecture
2. Statelessness
   1. 각 요청은 서로 독립적이어야 한다. 요청들이 서로 연속적이거나 의존적인 관계를 가진 것이 아니라, 요청간에 서로 관계가 없는 것이 stateless의 의미이다.
   2. IP, HTTP 는 stateless protocol의 예시이고, TCP, FTP는 stateful protocol의 예시라고 한다.
3. Cacheability
   1. 서버의 응답(response)이 캐싱 가능해야 한다. 잘 관리되는 캐싱은 확장성과 성능에 이점이 있다고 한다.
   2. 캐시는 브라우저 캐시 저장소나 클라이언트 머신 메모리에 저장된다.
4. Layered System
   1. 클라이언트 입장에서 서버 측에 얼마나 많은 서버가 있는지, 또는 서버 사이에 gateway 서버가 있는지 없는지 등을 신경쓰지 않고, 서버에서 제공하는 공통된 API layer 하나로 서버와 통신할 수 있는 환경을 말한다. (즉 서버 구조에 상관 없에 클라이언트는 API 사용법만 알면 되도록 설계가 되어야 한다는 것)
      1. e.g. proxy / load balancer가 클라이언트와 서버 사이에 있는 경우
   2. security layer또한 business logic과 분리하여 추가할 수 있을 것이다.
5. Code on demand (optional)
   1. 클라이언트가 원한다면 클라이언트에서 수행하는 코드를 서버가 보내줄 수 있어야 한다는 내용이라고 한다.
6. Uniform interface (실질적으로 REST를 결정하는 가장 중요한 요소)
   1. Resource identification in requests
      1. 서버의 각 자원(resource / data)는 클라이언트의 요청에 의해 식별(identify)될 수 있어야 한다. (예를들면 서로 다른 URI로 각 데이터를 요청하는 것을 말한다)
         1. e.g. URL로 resource(data)를 JSON이라는 representation으로 요청하는 것.
   2. Resource manipulation through representations
      1. 클라이언트가 서버로부터 리소스를 전달받으면(물론 JSON등의 representation 형태로) 해당 리소스를 어떻게 수정(modify) 또는 삭제(delete)할 수 있는지, 그 방법에 대한 정보도 함께 전달 받아야 한다. 즉 클라이언트는 리소스를 가지고 있기만 하다면, 그 리소스를 수정, 삭제할 방법도 알고 있어야 한다는 것이다. (When a client holds a representation of a resource, including any metadata attached, it has enough information to modify or delete the resource's state.)
   3. Self-descriptive messages
      1. 서버가 보내는 메시지는 클라이언트가 해당 메시지를 어떻게 처리해야 하는지에 대한 정보를 스스로 포함하고 있어야 한다.
      2. 예를들면 HTTP header에서 content-type을 지정해서 이게 JSON인지 아니면 어떤 다른 파일인지 알려주는게 이 규칙을 만족하는 내용이라고 한다. (아니면 media-type을 알려줘서 어떤 parser를 사용해야 할지를 명시한다던가)
   4. Hypermedia as the engine of application state (HATEOAS)

      1. 마치 인간이 어떤 웹사이트의 홈페이지에 접속하면 그 사이트 내에서 이동할 수 있는 여러 링크들의 Navigation을 제공받는 것처럼, 구체적인 예를 들자면,

      2. REST API도 만약 클라이언트에서 어떤 URL에 대한 요청을 보낸다면, 서버는 응답안에 해당 URL의 하위 path들에는 어떤 것들이 있는지 목록을(즉 개념으로 치면 자원resource에 대한 하이퍼링크를hyperlinks) 포함해야 한다는 것이다.

         1. 예를들어 클라이언트가 /accounts/12345 라는 URL에 요청을 한다면,

         2. 서버는 응답안에 다음과 같은 내용을 포함해야 한다.

            

            • 보면 12345라는 account에서는 deposit, withdraw, transfer, close 동작을 수행할 수 있고, 또 각각의 실제 URL path 값까지 포함하고 있다.

              ⇒ 따라서 클라이언트가 각 URL을 하드코딩하지 않고 서버에서 제공하는 데이터를 통해 코드를 작성할 수 있고, 이게 HATEOAS가 의도하는 바다.

      3. HATEOAS는 근데 실제로 지켜지는 경우가 거의 없다고 한다.

• 빨간색은 HTTP를 사용할 경우 만족할 수 있는 제약 조건들이다.

RESTful API - 의미, 이론과 실제

• REST architectural constraints를 만족하는 웹 API를 RESTful API라고 한다.
• 따라서 엄밀히 따지면 RESTful API가 되기 위해서는 위 6가지 제약 조건을 지켜야 하는데, 실제로 실무에서 이걸 다 지키는 경우는 없고, 보통은 그냥 HTTP를 만족시키게 되면 기본적인 RESTful API라고 부를 수 있다고 한다. (드림코딩 강의)

그럼 HTTP는 뭐냐?

• HyperText Transfer Protocol의 약자로, 서버와 클라이언트 간의 통신에서 어떻게 메시지와 데이터를 주고받을 것인지를 정해놓은 규칙이다.