27일차 #100DaysOfCode — REST API

Source: Dev.to

REST API란 무엇인가요?

REST API를 레스토랑의 웨이터에 비유해 보세요:

• 당신(클라이언트/앱)이 음식을 요청합니다.
• 주방(서버/데이터베이스)이 음식을 준비합니다.
• 웨이터(REST API)가 요청을 받아 전달하고 결과를 가져옵니다.

주방에 직접 들어가지 않으며, 오직 웨이터를 통해서만 — 표준화되고 합의된 문구를 사용해 소통합니다.

그렇다면 REST란 무엇인가요?

**REST(Representational State Transfer)**는 두 애플리케이션이 인터넷을 통해 통신할 수 있게 하는 일련의 규칙입니다. 클라이언트는 표준 HTTP 메서드를 사용해 서버와 대화하고 데이터를 가져오거나 변경합니다.

REST API의 핵심 HTTP 메서드

REST API의 실제 예시

날씨 앱이 로드될 때, 다음과 같은 요청을 보낼 수 있습니다:

GET https://api.weather.com/city=karachi

서버는 JSON 데이터로 응답합니다:

{
  "city": "Karachi",
  "temperature": "31°C",
  "condition": "Sunny"
}

앱이 날씨를 표시합니다 — API 덕분이죠.

REST에서 “리소스”란 무엇인가요?

리소스는 API가 다루는 데이터 조각을 의미합니다.

예시

• 사용자
• 게시물
• 제품
• 주문

각 리소스는 고유한 URL(엔드포인트라고도 함)을 가집니다:

/users
/posts
/products

RESTful 라우트 명명 규칙

REST는 동사가 아닌 명사에 초점을 맞춥니다.

올바른 RESTful 라우트

전체 사용자 조회

GET /users

사용자 생성

POST /users

단일 사용자 조회

GET /users/:id

사용자 업데이트

PUT /users/:id
PATCH /users/:id

사용자 삭제

DELETE /users/:id

잘못된 라우트 명명 (하지 말아야 할 예시)

POST /createUser
GET /getAllUsers
DELETE /deleteUser

이들은 URL에 동사를 사용하므로 REST 규칙에 어긋납니다.

REST API의 쿼리 파라미터

쿼리 파라미터는 결과를 필터링, 검색 또는 맞춤화할 수 있게 해줍니다.

GET /users?role=admin
GET /products?limit=10&page=2
GET /posts?sort=latest

요청 및 응답 구조

요청

• params – URL 내부의 값(예: /users/:id)
• query – 필터링/페이지네이션(예: ?page=2)
• body – POST/PUT/PATCH 요청에 사용되는 데이터
• headers – 메타데이터(인증 토큰, content‑type 등)

응답

• status code
• JSON body
• headers
• optional metadata (페이지네이션 정보, 타임스탬프 등)

일반적인 REST API 상태 코드

성공

• 200 OK – 요청 성공
• 201 Created – 새 리소스 생성
• 204 No Content – 성공했지만 응답 본문 없음

클라이언트 오류

• 400 Bad Request – 잘못된 입력
• 401 Unauthorized – 인증 필요
• 403 Forbidden – 인증은 되었지만 권한 없음
• 404 Not Found – 리소스를 찾을 수 없음

서버 오류

• 500 Internal Server Error – 서버 내부 오류

REST에서 멱등성

“멱등(Idempotent)”은 동일한 요청을 여러 번 보내도 결과가 동일함을 의미합니다.

최종 요약

REST API는 앱과 서버 사이의 메신저 역할을 합니다. 표준 HTTP 메서드를 사용해 데이터를 생성, 조회, 업데이트, 삭제할 수 있습니다. 다음을 이해한다면:

• 리소스
• 라우트
• 동사 (GET, POST, PUT, DELETE)
• 쿼리 파라미터
• 상태 코드
• 멱등성

…이미 REST API의 핵심을 파악한 것입니다.

코딩 즐겁게 하세요!