[Spring Boot] REST Api 란 무엇일까?

[REST Api 개념]

• Api 란?
  Application Programming Interface 의 약자로 컴퓨터나 컴퓨터 프로그램이 서로 소통할 수 있도록 제공하는 인터페이스이다.
  웹 환경에서의 api는 서버가 제공하는 기능들을(자원의 조회 등..) URI 의 형태로 클라이언트에게 제공하게 된다.
  

  

• REST 란?
  Representational State Transfer 의 약자로 HTTP 프로토콜을 이용한 웹 서비스 설계에서 주로 사용하는 설계 원칙이다.
  자원을 이름으로 구분하여 자원의 상태를 주고받는 모든 것들을 의미하며 네트워크 상에서 클라이언트와 서버 사이의 통신 규칙 이라 이해하면 될 것이다.

• REST Api 란?
  REST Api 는 REST의 설계원칙이 적용된 Api 를 의미하며 URI 로 자원의 형태를 표현하기 때문에 표현 규칙 또한 존재한다.
  1. 동사보다는 명사를, 대문자보다는 소문자를 사용한다.
  2. 복합명사의 경우 URI의 가독성을 높이기 위해 하이픈(-) 을 사용하며 밑줄(_) 은 사용하지 않는다.
  3. 파일의 확장자는 URI에 포함시키지 않는다.
  4. URI에는 동사 표현이 들어가면 안된다.

     http://localhost/user/get/id..

  5. 자원에 대한 행위 표현은 HTTP Method 를 사용하여 표현한다.
     GET : 자원을 조회할 때 사용한다.
     POST : 자원을 생성하거나 정보를 전달할때 사용한다.
     PUT/PATCH : 자원을 수정할 때 사용한다.
     (PUT 은 자원을 모두 업데이트 해야할 경우 사용한다. PATCH 는 자원의 일부를 업데이트 해야할 경우 사용한다.)
     DELETE : 자원을 삭제할 때 사용한다.

      POST      http://localhost/users     (생성)✅
      PUT/PATCH http://localhost/users/123 (수정)✅
      DELETE    http://localhost/users/123 (삭제)✅
      GET       http://localhost/users/123 (조회)✅
      GET       http://localhost/users     (전체조회)✅

  6. 경로 부분 중 변하는 부분은 유일한 값으로 대체한다.

      PUT/PATCH http://localhost/users/{id} 
      DELETE    http://localhost/users/{id} 
      GET       http://localhost/users/{id}

     URI 에서 {id} 값이 변화하므로 해당 id 값은 자원을 식별하기 위한 유일한 값이어야 한다.

[REST Api 설계원칙]

앞서 REST란 클라이언트와 서버가 데이터를 주고받는 방식에 대한 설계 원칙임을 이야기 하였다.
그렇다면 RESTful 한 설계를 하기 위해서 어떤 원칙들이 존재할까
REST 설계 원칙에는 총 6가지가 존재한다.

1. Client-server 구조 : 클라이언트와 서버는 서로 독립적이어야 하며, 클라이언트는 URI 리소스만을 알아야 한다.
   이 둘은 독립적으로 개발되거나 대체될 수 있어야 한다.

2. Stateless : 클라이언트의 요청에는 요청을 이해할 수 있는 모든 정보가 포함되어있어야 한다.
   서버는 요청에 대한 어떤 정보도 저장하지 않으며 세션이나 인증/인가 와 같은 정보는 클라이언트의 요청에 모두 포함되어야 한다.

3. Cacheable : 서버는 응답 헤더에 해당 요청의 캐싱 가능 여부를 제공해야하며 클라이언트는 이를 캐싱하여 서버와 클라이언트간의 통신 효율을 높인다.

4. Uniform interface : REST Api 에서는 일관된 인터페이스를 제공하도록 하기 위해 4가지의 설계원칙을 제공하고있다.

   • identification of resources : 요청 시 개별 자원을 식별할 수 있어야 한다.

   • manipulation of resources through representations : 어떤 자원에 대하여 작업하기 위한 적절한 표현과 데이터가 갖추어져 있다면 서버는 자원을 조작할 수 있다.

     PUT /users/123                    ← 어떤 자원인지 명시
     Content-Type: application/json    ← 메타데이터 (JSON 형식이라고 알려줌)
     Authorization: Bearer token123    ← 메타데이터 (권한 정보)
     
     {                                ← 적절한 표현 (JSON)
     "name": "김영희",
     "email": "kim@example.com",
     "phone": "010-1234-5678"
     }

5. Layered system : REST는 다중 계층 구조를 가지도록 허용한다. (Api 서버와 DB 서버, 인증 서버를 분리하는 등..)
   각 계층은 다른 계층의 대한 정보를 얻을 수 없다. 클라이언트는 Api 서버 하고만 상호작용하며 이외의 계층과는 상호작용 하거나 알 수 없다.

6. Code on demand(필수아님) : 서버가 클라이언트에서 실행시킬 수 있는 로직을 전송하여 클라이언트가 사전에 구현해야할 기능을 간소화시킬 수 있다.

   {
   "formConfig": {
    "fields": [
      {"type": "text", "name": "username", "required": true},
      {"type": "email", "name": "email", "required": true}
    ]
   },
   "renderScript": "function renderForm(config) { config.fields.forEach(field => { /* 폼 생성 로직 */ }); }"
   }