김박사의 공부일지

REST API : 웹 상에서 데이터나 기능을 "규칙 있게" 주고 받는 방식

1. REST, REST API가 뭐야?

1) REST(Representational State Transfer)

REST는 웹 서비스를 설계할 때 지켜야할 스타일/원칙

1. 리소스(Resource) 중심

• 서버가 제공하는 대상(데이터/기능)을 모두 "리소스"로 간주
• 예)사용자, 게시글, 주문, 프로젝트 ...
• 각 리소스는 고유한 URL(URI)로 표현:
  - /users
  - /users/1
  - /projects/123/components

2. HTTP 메서드로 동작 표현

• GET:조회
• POST:생성
• PUT:전체 수정
• PATCH:부분 수정
• DELETE:삭제

예를 들어 "1번 사용자 조회"는

• GET /users/1

3. 무상태성(Stateless)

• 서버는 클라이언트의 상태를 세션으로 기억하지 않음
• 각 요청은 필요한 정보를 전부 들고 와야 함
  (토큰, 요청 데이터 등)

4. 표현(Representation)

• 리소스는 여러 방식으로 표현 가능
• 요즘은 거의 다 JSON 사용:

{
	"id": 1,
    "name": "name"
}

5. 일관된 인터페이스

• URL, 메서드, 응답 형식을 일관되게 설계하면 클라이언트 입장에서 이해하기 편함

2. RESTful API란?

"REST 원칙을 잘 지키면서 만든 API"를 보통 RESTful API라고 말함

예를 들어 회원 관리 API라면:

여기에 상태 코드까지 맞춰주면 더 RESTful 해짐

• 200 OK, 201 Created, 400 Bad Request, 404 Not Found, 500 Internal Server Error ...

3. REST API 설계 순서

1. 무슨 리소스를 다룰지 정함

• 예) User, Project, Post, Order 등

2. 각 리소스 별로

• 어떤 기능이 필요한지 (조회/등록/수정/삭제) 정함
• URL/HTTP 메서드 설계

예) 게시글(Post) 리소스

• GET /posts: 전체조회
• GET /posts/{id}: 상세조회
• POST /posts: 생성
• PUT /posts/{id}: 수정
• DELETE /posts/{id}: 삭제

3. 요청/응답 JSON 형식 정의

• 예) 게시글 생성 요청 바디:

{
  "title": "첫 글입니다",
  "content": "내용..."
}

• 응답:

{
  "id": 1,
  "title": "첫 글입니다",
  "content": "내용...",
  "createdAt": "2025-11-25T12:00:00"
}

4. 에러 케이스 정의

• 없는 ID 요청 시 → 404
• 필수 값 누락 → 400
• 서버 내부 오류 → 500