01 / 15
SESSION 28 · Part 6 서버/DB

REST API

URL로 자원을 가리키고, HTTP 메서드로 행위를 말한다 — 프론트와 백을 잇는 표준 언어

02 / 15
🎯

이 세션에서
배우는 것

📜
REST 원칙
자원과 행위를 분리해 표현하는 설계 원칙을 이해한다
🔗
엔드포인트 설계
URL과 HTTP 메서드의 조합을 읽고 설계한다
📦
JSON
데이터 교환의 표준 형식을 다룬다
03 / 15
💭

REST
표준처럼 쓸까?

서비스마다 요청 방식이 제각각이라면, 새 프로젝트마다 처음부터 배워야 한다.
REST는 "URL은 자원, 메서드는 행위" 라는 단순한 규칙으로 이 혼란을 정리한다.

한 번 배우면 어느 회사 API든 같은 감각으로 읽을 수 있다.

04 / 15

HTTP 메서드 — CRUD의 네 동사

같은 URL이라도 어떤 메서드로 호출하느냐에 따라 의미가 완전히 달라진다.

👀
GET
조회 · Read
POST
생성 · Create
✏️
PUT
수정 · Update
🗑️
DELETE
삭제 · Delete
05 / 15
📜

REST 원칙 —
더 깊게 이해하기

REST는 6가지 제약 조건을 가진 아키텍처 스타일이다. 핵심만 쉽게 이해하자.

1
무상태 (Stateless)
각 요청은 독립적으로 완결되어야 한다. 서버는 이전 요청을 기억하지 않으므로 매 요청에 필요한 정보를 모두 담는다.
2
균일 인터페이스 (Uniform Interface)
URL로 자원을 식별하고, HTTP 메서드로 행위를 표현하는 일관된 방식. GET /users, DELETE /users/1처럼.
3
클라이언트-서버 분리
UI(프론트)와 데이터 처리(백)를 분리. 각각 독립적으로 발전할 수 있고 다양한 클라이언트(웹·앱)가 같은 API를 사용한다.
4
캐시 가능 (Cacheable)
응답에 캐시 가능 여부를 명시. GET 요청 결과를 브라우저가 캐시하면 동일 요청 시 서버 부하 없이 빠르게 반환.
06 / 15

엔드포인트 실전 예시

자원(users)을 두고 메서드와 경로를 조합해 네 가지 동작을 표현한다.

GET    /api/users         → 사용자 목록 조회
GET    /api/users/1       → id=1 사용자 단건 조회
POST   /api/users         → 새 사용자 생성
PUT    /api/users/1       → id=1 사용자 정보 수정
DELETE /api/users/1       → id=1 사용자 삭제

핵심: URL은 명사(자원), 메서드는 동사(행위).

07 / 15
🌤️

날씨 앱 —
실제로는 어떻게?

날씨 앱을 열 때 기상청 API를 호출하는 과정을 따라가보자.

앱 실행
위치 정보 획득
GET 요청
/weather?lat=37&lon=127
기상청 서버
DB 조회·처리
JSON 응답
화면에 날씨 표시

핵심: URL에 위치 정보를 쿼리로 담아 GET 요청 → 서버는 JSON으로 응답. API 키로 사용자를 인증한다.

08 / 15
📦

데이터의 공용어 — JSON

서버와 클라이언트가 주고받는 데이터 형식. 사람과 기계 모두 읽기 쉽다.

{
  "id": 1,
  "name": "김철수",
  "age": 30,
  "roles": ["admin", "user"]
}

Postman 같은 도구로 코드 없이도 요청을 보내고 응답을 확인할 수 있다.

09 / 15
📱

실생활에서
이렇게 쓰여요

우리가 매일 사용하는 앱과 서비스 속에 이 개념이 녹아 있다.

👤
카카오 로그인 API
앱에서 "카카오로 로그인" → 카카오 OAuth API 호출 → 사용자 토큰 발급 → 서비스 인증 완료
🗺️
네이버 지도 API
배달앱 주소 검색 → 네이버 지도 API에 GET 요청 → 좌표 반환 → 지도에 핀 표시
💳
결제 PG사 API
결제 버튼 클릭 → PG사 REST API에 POST 요청 → 결제 승인 JSON 응답 → 주문 완료 처리

💡 이 개념이 없다면 매 서비스마다 로그인·지도·결제를 처음부터 직접 개발해야 했을 것이다.

10 / 15
💡

자주 하는
오해 바로잡기

이렇게 생각하기 쉽지만, 실제로는 조금 다릅니다.

❌ 흔한 오해
  • API = 앱(Application)
  • REST API = HTTP 전부
  • API 키 = 비밀번호
✓ 실제로는
  • API는 Application Programming Interface — 소프트웨어 간 소통 규격
  • REST는 HTTP를 사용하는 아키텍처 스타일 중 하나 (GraphQL도 HTTP 사용)
  • API 키는 사용자 식별·사용량 추적 목적, 비밀번호와 용도가 다름
11 / 15
📋

REST API는 식당 메뉴판이다

메뉴에 따라 주문 방법이 정해져 있듯이, 엔드포인트마다 요청 규칙이 정해져 있다.

📋 메뉴판 비유
메뉴 항목
=
엔드포인트 — /users, /orders ...
주문 방식
=
HTTP 메서드 — GET · POST · PUT · DELETE
그릇 규격
=
JSON 구조 — 정해진 키와 타입
주문서
=
Request Body — POST/PUT 시 함께 보내는 데이터
12 / 15
🤖

이걸 알면
AI와 이렇게 대화해요

이 개념을 이해하면 Claude나 ChatGPT를 훨씬 잘 활용할 수 있다.

👤
날씨 API 연동하고 싶어요.
🤖
어떤 날씨 API를 사용하실 건가요? 무료 API가 여러 개 있어요.
👤
OpenWeatherMap API를 JavaScript fetch로 호출해서 서울 현재 날씨를 표시하는 코드 작성해줘. API 키는 MY_KEY로 대체해서.
🤖
fetch(`https://api.openweathermap.org/data/2.5/weather?q=Seoul&appid=MY_KEY&units=metric`) 으로 GET 요청하고 .then(res => res.json())으로 파싱하는 전체 코드를 작성해드릴게요.
13 / 15

이렇게
이해하셨나요?

맞게 이해하셨어요
REST API는 HTTP를 기반으로 URL(자원)과 메서드(행위)를 분리한 표준화된 데이터 교환 방식
이렇게는 아니에요
REST API를 쓰면 실시간 데이터가 자동으로 업데이트된다 (Polling이나 WebSocket이 필요)
맞게 이해하셨어요
GET은 조회, POST는 생성, PUT은 수정, DELETE는 삭제 — URL은 명사, 메서드는 동사
이렇게는 아니에요
API 키를 알면 해당 서비스의 모든 기능을 제한 없이 사용할 수 있다

💪 REST를 이해하면 모르는 API 문서도 URL과 메서드만 보면 바로 파악할 수 있어요!

14 / 15
📌

핵심 정리

📜
REST
URL = 자원
메서드 = 행위
🔁
CRUD
GET · POST
PUT · DELETE
🔗
엔드포인트
자원을 가리키는
일관된 URL 체계
📦
JSON
데이터 교환의
사실상 표준
🧪
Postman
코드 없이
API 테스트
🌍
표준의 힘
한 번 배우면
어디든 적용
15 / 15
🚀

다음 세션
Session 29 · 관계형 데이터베이스 (SQL)

JavaScript로 서버 코드를 짜는 세상을 연 주인공.
V8 엔진, 이벤트 루프, 그리고 Express로 API 서버 만들기.

💡 기억할 것: REST는 URL = 명사, 메서드 = 동사라는 문법이다.

슬라이드 목록