본문 바로가기
Spring/10. rest-api

REST API의 개념

by 989898 2025. 3. 8.

RESTful API란 무엇인가?

RESTful API는 REST 원칙을 잘 지켜서 만든 API를 말합니다.
단순히 URL 명칭만 잘 설계하는 것이 아니라, 다음과 같은 원칙을 모두 지켜야 합니다.

  • **자원(Resource)**을 명확하게 URL로 표현해야 합니다.
  • **행위(Action)**는 URL에 넣지 않고, HTTP 메서드(GET, POST, PUT, DELETE 등)로 표현해야 합니다.
  • 서버와 클라이언트는 실제 데이터(리소스)를 직접 주고받지 않고, 그 리소스를 나타낸 데이터(표현, Representation)를 주고받습니다.
  • 메시지는 스스로 설명 가능해야 합니다 (메시지만 보고 요청과 응답의 의미를 알 수 있어야 함).
  • 하이퍼링크(HATEOAS)를 통해 클라이언트가 다음 행동을 쉽게 결정할 수 있도록 도와줍니다.
  • 서버와 클라이언트가 서로 독립적이어야 하고(Client-Server 구조), 서버는 클라이언트의 상태를 저장하지 않아야 합니다(stateless).

즉, RESTful API는 단순히 URL만 잘 짓는 것이 아니라 위의 원칙들을 모두 지키면서 설계한 API입니다.

RESTful API와 렌더링 방식의 관계

RESTful API 자체가 반드시 클라이언트 사이드 렌더링(CSR)만 사용하는 것은 아닙니 다. 하지만 일반적으로 RESTful API는 데이터를 JSON 형태로 제공하며, 클라이언트가 이 데이터를 받아 JavaScript로 화면을 동적으로 구성하는 방식(CSR)에 적합합니다.

반면 MVC 방식은 일반적으로 서버에서 미리 HTML을 만들어 보내주는 서버 사이드 렌더링(SSR)을 사용합니다. MVC에서는 보통 HTML 템플릿을 서버에서 미리 만들어서 전달하기 때문입니다.

직관적인 이해를 위한 예시

블로그 게시글 삭제 요청을 예로 들어봅시다.

❌ REST하지 않은 예시

GET /posts/delete?id=2
 

이 URL은 문제가 있습니다:

  • URL에 delete라는 행위가 들어갔습니다. (URL은 행위를 나타내면 안 되고 오직 자원만 나타내야 함)
  • GET 메서드는 데이터를 가져오는 용도로만 사용되어야 하는데 삭제라는 행위를 수행하려고 했습니다.

✅ RESTful한 올바른 예시

DELETE /posts/2
 

이 URL은:

  • 오직 자원만 나타냅니다 (posts/2라는 자원을 명확히 표현).
  • DELETE라는 HTTP 메서드를 통해 삭제 행위를 명확하게 표현했습니다.

결론적으로 정리하면?

  • RESTful API란 단순히 URL 이름만 잘 정하는 게 아니라 위에서 말한 REST 원칙(자원 중심의 URL 설계 + HTTP 메서드를 통한 행위 표현 + 자기 설명적인 메시지 + 하이퍼링크 제공 등)을 모두 지켜 만든 API를 뜻합니다.
  • 일반적으로 RESTful API는 JSON 데이터를 주고받기 때문에 클라이언트가 이 데이터를 받아 화면을 그리는 **클라이언트 사이드 렌더링(CSR)**과 자주 함께 사용됩니다.
  • 반면, 전통적인 MVC 방식은 서버에서 직접 HTML 페이지를 만들어 보내주는 서버 사이드 렌더링(SSR) 방식을 주로 사용합니다.


🔍 REST API의 개념 (직관적 이해)

"서버와 클라이언트가 소통할 때 실제 자원(리소스) 자체를 직접 주고받는 게 아니라, 그 자원을 나타낸 데이터를 주고받는다" 라는 말이 어렵게 느껴질 수 있습니다.

이것을 쉽게 이해하려면 다음과 같은 예시를 생각해보세요.

📌 예시 상황

어떤 서버가 프로그래머 정보를 관리한다고 가정해봅시다.
서버에는 프로그래머의 정보가 데이터베이스(DB)에 저장되어 있습니다.

  • 실제 리소스(Resource): 서버의 DB에 저장된 프로그래머 정보
    • 예) 닉네임: Namespacinator, 파워 레벨: 5

이때 클라이언트(앱이나 브라우저)는 이 정보를 얻고 싶습니다.
하지만 클라이언트는 서버의 DB에 직접 접근할 수 없습니다. 대신 서버에게 요청을 보내고, 서버는 이 요청에 맞춰 데이터를 보내줍니다.

그런데 이때 서버가 DB에 있는 실제 데이터를 그대로 보내는 것이 아니라, 그 데이터를 JSON이나 XML 같은 형식으로 **"표현(Representation)"**하여 전달합니다.

🖥️ 코드로 보는 REST API 예시

✅ 클라이언트가 프로그래머 정보를 요청할 때 (GET 요청)

클라이언트가 서버에게 "Namespacinator라는 프로그래머 정보를 주세요"라고 요청합니다.

// 클라이언트 코드 (JavaScript)
fetch('https://api.example.com/programmers/Namespacinator')
  .then(response => response.json())
  .then(data => {
    console.log(data);
  });
 

서버는 이 요청에 대해 다음과 같은 JSON 형태의 응답을 보냅니다:

{
  "nickname": "Namespacinator",
  "powerLevel": 5
}

 

여기서 중요한 점은,
이 JSON 데이터는 실제 DB에 저장된 프로그래머 자체(리소스)가 아닙니다.
단지 현재 상태를 표현한 데이터일 뿐입니다.

즉, 서버와 클라이언트는 실제 리소스를 주고받지 않고, **리소스의 현재 상태를 표현한 데이터(Representation)**를 주고받습니다.

📌 왜 이렇게 하는 걸까?

실제 데이터 자체를 직접 주고받으려면 매우 비효율적이고 복잡합니다.
예를 들어, DB에 있는 데이터를 직접 클라이언트에게 보내면 보안 문제도 있고, 클라이언트가 이를 처리하기도 어렵습니다.

대신 JSON이나 XML 같은 표준화된 형식으로 표현하여 보내면:

  • 클라이언트가 쉽게 데이터를 해석하고 사용할 수 있습니다.
  • 여러 플랫폼(웹, 모바일 등)에서 쉽게 사용할 수 있습니다.
  • 필요한 정보만 간추려 보낼 수 있어 효율적입니다.

📌 추가적인 코드 예시

이번엔 프로그래머 정보를 수정하는 경우를 생각해봅시다.

클라이언트는 다음과 같이 수정된 데이터를 JSON 형태로 만들어 서버에 보냅니다:

// 클라이언트에서 서버로 보내는 요청 (JavaScript)
fetch('https://api.example.com/programmers/Namespacinator', {
  method: 'PUT', // 수정하겠다는 의미
  headers: {
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    nickname: 'Namespacinator',
    powerLevel: 10 // powerLevel을 기존 5에서 10으로 변경
  })
})
.then(response => response.json())
.then(updatedData => {
  console.log(updated data);
});
 

여기서도 클라이언트는 실제 DB 데이터를 직접 수정하지 않고, **"수정하고 싶은 상태를 표현한 데이터"**만 서버로 전달합니다.
서버는 이 표현을 보고 실제 DB의 리소스를 업데이트합니다.

📌 정리하면?

REST API란 결국:

클라이언트와 서버가 소통할 때 실제 데이터(리소스)를 직접 주고받지 않고, 그 데이터의 현재 상태를 나타낸 표현(Representation)을 주고받으며 소통하는 방식입니다.

이렇게 하면 서로 독립적이고 효율적인 시스템을 만들 수 있고, 다양한 플랫폼에서 쉽게 사용할 수 있어 널리 활용됩니다.


🔍 "실제 데이터(리소스)를 주고받지 않고 표현을 주고받는다"는 말의 진짜 의미

이 말은 "서버가 DB에 저장된 실제 데이터를 그대로(원본 그대로) 클라이언트에게 직접 보내지 않는다" 라는 의미입니다.

즉, 서버가 갖고 있는 실제 데이터(리소스)는 보통 데이터베이스(DB)에 저장되어 있습니다.
이 DB의 데이터는 서버 내부에서만 접근 가능하고, 클라이언트는 이 DB에 직접 접근할 수 없습니다.

서버는 클라이언트가 요청하면, DB에서 데이터를 꺼내서 클라이언트가 이해할 수 있는 형태로 변환하여 전달합니다. 이 변환된 데이터를 REST에서는 **표현(Representation)**이라고 부릅니다.

📌 직관적인 예시로 이해하기

예를 들어, 서버의 DB에 다음과 같은 프로그래머 정보가 있다고 합시다.

✅ 서버 내부의 실제 리소스 (데이터베이스)

 

이것이 바로 서버가 갖고 있는 **실제 데이터(리소스)**입니다.
하지만 이 데이터를 그대로 클라이언트에게 보내면 다음과 같은 문제가 생깁니다:

  • 클라이언트는 암호화된 비밀번호(password_hash)나 생성일(created_at) 같은 민감하거나 불필요한 정보를 알 필요가 없습니다.
  • 클라이언트가 이해하기 어려운 형태일 수 있습니다 (예: 날짜 포맷, 암호화된 값 등).

그래서 서버는 이 데이터를 그대로 보내지 않고, 클라이언트가 필요한 정보만 JSON 형식으로 변환하여 보냅니다.

✅ 서버가 클라이언트에게 보내주는 표현(Representation)

{
  "id": 1,
  "nickname": "Namespacinator",
  "powerLevel": 5
}

 

이 JSON 데이터는 실제 리소스 자체(DB의 원본 데이터)가 아니라,
그 리소스를 클라이언트가 이해하기 쉽도록 변환한 **표현(Representation)**입니다.

즉, REST API에서 말하는 **"실제 리소스를 주고받지 않는다"**라는 말은:

  • 서버 내부의 원본 데이터를 그대로 보내지 않고
  • 클라이언트가 이해하기 쉬운 형태로 변환한 데이터를 보낸다

라는 의미입니다.

📌 표현(Representation)을 사용하는 이유

왜 REST에서는 굳이 이렇게 표현을 사용할까요?

  1. 보안과 안전성: 민감한 원본 데이터를 감추고 필요한 정보만 제공합니다.
  2. 유연성: JSON, XML 등 다양한 형태로 표현할 수 있어 다양한 플랫폼에서 쉽게 사용할 수 있습니다.
  3. 독립성: 서버 내부의 데이터 구조(DB)가 바뀌어도 클라이언트에게 보내는 Representation만 유지하면 클라이언트는 아무런 영향을 받지 않습니다.

📌 결론적으로 정리하면?

REST API에서 말하는 "실제 데이터를 주고받지 않고 표현을 주고받는다"라는 말은:

서버 내부의 원본 데이터를 그대로 보내지 않고, 클라이언트가 이해할 수 있도록 필요한 정보만 골라 JSON이나 XML 형태로 변환하여 보낸다

는 의미입니다.

이렇게 하면 서버와 클라이언트 간의 독립성이 높아지고, 유연성과 안전성이 향상됩니다.


질문 : 오케이 이제야 완벽히 이해했어. restful api는 rest의 원칙을 잘 지킨 api이며, 형식은 post/1 이런식으로 동작은 url로 표시하지 않고 오직 자원의 정보만 서버에 보내는 형식이고 rest api를 사용하는 이유는 클라이언트가 브라우저에만 종속되지 않고 여러 기기를 통해서 서버로 접속할수 있기 때문에 json으로 데이터를 보내는 api인 거지?

맞습니다! 이제 RESTful API의 개념과 이유를 완벽히 이해하셨습니다. 아래에 다시 간단히 정리해드리겠습니다.

✅ RESTful API란?

  • RESTful API REST 원칙을 잘 지켜 설계된 API를 의미합니다.
  • REST 원칙이란:
    • URL은 **자원(Resource)**만 나타내야 합니다. (예: /posts/1)
    • 동작(행위)은 HTTP 메서드(GET, POST, PUT, DELETE 등)으로 표현합니다.
    • 클라이언트와 서버는 데이터를 주고받을 때 JSON이나 XML 같은 형식을 사용하며, 실제 리소스가 아닌 **리소스의 표현(Representation)**을 주고받습니다.
    • 서버는 클라이언트의 상태를 저장하지 않고(stateless), 요청 메시지만 보고 응답합니다.

✅ RESTful API를 사용하는 이유

1. 다양한 클라이언트 지원

RESTful API는 브라우저뿐만 아니라 모바일 앱, 데스크톱 앱, IoT 기기 등 다양한 클라이언트에서 사용할 수 있습니다.
이는 JSON 같은 표준화된 데이터 형식을 사용하기 때문에 가능합니다.

2. 플랫폼 독립성

RESTful API는 서버와 클라이언트가 서로 다른 언어와 플랫폼을 사용해도 문제없이 통신할 수 있습니다.
예를 들어, 서버는 Python으로 개발되어 있고, 클라이언트는 JavaScript로 동작하는 경우에도 JSON 데이터를 통해 쉽게 소통할 수 있습니다.

3. 확장성과 유연성

RESTful API는 서버와 클라이언트를 독립적으로 개발할 수 있게 해줍니다.
서버의 내부 구조(DB 설계 등)가 변경되더라도 클라이언트는 JSON 응답만 유지되면 영향을 받지 않습니다.

✅ RESTful API의 동작 방식 예시

  • 클라이언트가 서버에 다음과 같은 요청을 보냅니다:
  • 서버는 이 요청을 처리하고, 다음과 같은 JSON 데이터를 응답합니다.

 

 

✅ 결론

RESTful API는 REST 원칙을 잘 지켜 설계된 API로, URL은 자원을 표현하고 동작은 HTTP 메서드로 구분하며, JSON 데이터 형식으로 서버와 클라이언트가 소통합니다.
이를 통해 브라우저뿐만 아니라 다양한 기기에서 서버와 쉽게 통신할 수 있으며, 플랫폼 독립성과 확장성을 제공합니다.

이제 RESTful API의 개념과 이유를 명확히 이해하신 것 같습니다! 🎉

 

강의에서 나온 RESTFUL API 설계의 여러가지 장점 중 하나인데 적은 엔드 포인트로 즉, 적은 URI를 가지고 HTTP의 메서드를 다양하게 함으로써 여러가지 API를 설계하는 것이 가능하다는 것이 특징이다.