REST API 이해하기: HTTP 메서드, 상태 코드, JSON 응답까지

티스토리 뷰

개발 기초

REST API 이해하기: HTTP 메서드, 상태 코드, JSON 응답까지

KimGPT 2026. 5. 11. 16:04

웹 개발을 하다 보면 거의 반드시 API라는 말을 만나게 됩니다.

프론트엔드에서 백엔드로 데이터를 요청할 때도 API를 사용하고, 모바일 앱이 서버와 통신할 때도 API를 사용합니다.
외부 서비스의 데이터를 가져오거나, 결제 시스템과 연동하거나, 관리자 페이지에서 데이터를 조회할 때도 API가 사용됩니다.

그중 웹에서 가장 자주 접하는 방식이 REST API입니다.

REST API는 HTTP를 기반으로 리소스를 조회하고, 생성하고, 수정하고, 삭제하는 방식으로 설계됩니다.
처음에는 GET, POST, PUT, DELETE 같은 HTTP 메서드만 외우게 되지만, 실제로는 URL 설계, 상태 코드, JSON 응답, 에러 처리, 인증 방식까지 함께 이해해야 합니다.

이번 글에서는 REST API를 처음 배울 때 꼭 알아야 하는 개념을 중심으로 정리해보겠습니다.

API란 무엇인가?

API는 Application Programming Interface의 약자입니다.

쉽게 말하면, 프로그램과 프로그램이 서로 정해진 방식으로 대화하기 위한 약속입니다.

예를 들어 프론트엔드 화면에서 게시글 목록을 보여줘야 한다고 해보겠습니다.

브라우저는 직접 데이터베이스에 접근하지 않습니다.
대신 백엔드 서버에 요청을 보냅니다.

프론트엔드
→ 게시글 목록을 주세요
→ 백엔드 API
→ 데이터베이스 조회
→ JSON 응답 반환

백엔드는 요청을 받아 필요한 데이터를 조회하고, 프론트엔드가 이해할 수 있는 형태로 응답합니다.

이때 프론트엔드와 백엔드 사이의 약속이 API입니다.

API에는 여러 종류가 있습니다.

REST API
GraphQL API
gRPC
WebSocket API
외부 서비스 SDK

그중 REST API는 HTTP 기반 웹 서비스에서 가장 널리 사용되는 방식 중 하나입니다.

REST API란?

REST는 Representational State Transfer의 약자입니다.

REST API는 웹의 기본 구조인 HTTP를 활용해 리소스를 다루는 API 설계 방식입니다.

여기서 중요한 단어는 리소스(resource)입니다.

리소스는 API에서 다루는 대상입니다.

예를 들어 블로그 서비스를 생각해보면 다음이 리소스가 될 수 있습니다.

사용자
게시글
댓글
카테고리
태그

쇼핑몰이라면 다음이 리소스가 될 수 있습니다.

상품
주문
장바구니
결제
배송지

REST API에서는 이런 리소스를 URL로 표현하고, HTTP 메서드로 어떤 행동을 할지 나타냅니다.

GET /posts
→ 게시글 목록 조회

POST /posts
→ 게시글 생성

GET /posts/1
→ 1번 게시글 조회

PATCH /posts/1
→ 1번 게시글 일부 수정

DELETE /posts/1
→ 1번 게시글 삭제

즉, REST API는 다음 두 가지를 함께 봐야 합니다.

URL
→ 어떤 리소스를 대상으로 하는가?

HTTP 메서드
→ 그 리소스에 어떤 행동을 하는가?

REST API 요청과 응답 흐름

REST API는 보통 클라이언트와 서버 사이의 요청과 응답으로 동작합니다.

예를 들어 사용자가 게시글 목록 페이지에 들어갔다고 해보겠습니다.

브라우저가 백엔드 서버에 요청을 보냅니다.
백엔드 서버가 요청 URL과 HTTP 메서드를 확인합니다.
필요한 경우 데이터베이스를 조회합니다.
결과를 JSON 형태로 만듭니다.
HTTP 상태 코드와 함께 응답합니다.
브라우저는 응답 데이터를 화면에 렌더링합니다.

흐름을 단순화하면 다음과 같습니다.

클라이언트
→ HTTP 요청
→ 서버
→ 비즈니스 로직 처리
→ 데이터베이스 조회 또는 변경
→ JSON 응답
→ 클라이언트

HTTP 메서드 이해하기

REST API에서 가장 먼저 익혀야 하는 것은 HTTP 메서드입니다.

HTTP 메서드는 요청의 목적을 나타냅니다.

대표적으로 다음 메서드를 많이 사용합니다.

GET
POST
PUT
PATCH
DELETE

각각의 역할을 하나씩 살펴보겠습니다.

GET: 리소스 조회

GET은 데이터를 조회할 때 사용합니다.

예를 들어 게시글 목록을 조회하는 API는 다음처럼 만들 수 있습니다.

GET /posts

특정 게시글 하나를 조회할 때는 리소스 ID를 URL에 포함할 수 있습니다.

GET /posts/1

GET 요청은 보통 서버의 데이터를 변경하지 않아야 합니다.

예를 들어 게시글 목록을 조회한다고 해서 게시글이 새로 생성되거나 삭제되면 안 됩니다.

GET은 다음 상황에 적합합니다.

목록 조회
상세 조회
검색 결과 조회
필터링된 데이터 조회

예시는 다음과 같습니다.

GET /posts
GET /posts/1
GET /users/10
GET /products?category=book
GET /orders?status=paid

검색 조건이나 필터 조건은 보통 쿼리 파라미터로 표현합니다.

GET /posts?category=django&page=2

POST: 리소스 생성

POST는 새로운 리소스를 생성할 때 자주 사용합니다.

예를 들어 게시글을 새로 작성하는 API는 다음처럼 만들 수 있습니다.

POST /posts
Content-Type: application/json

{
  "title": "REST API 이해하기",
  "content": "REST API의 기본 개념을 정리합니다."
}

서버는 요청 본문에 담긴 데이터를 받아 새 게시글을 생성합니다.

생성에 성공하면 보통 201 Created 상태 코드를 반환할 수 있습니다.

HTTP/1.1 201 Created
Content-Type: application/json

{
  "id": 1,
  "title": "REST API 이해하기",
  "content": "REST API의 기본 개념을 정리합니다."
}

POST는 다음 상황에 적합합니다.

회원가입
게시글 생성
댓글 작성
주문 생성
로그인 요청
파일 업로드 요청

다만 로그인처럼 새 리소스를 생성한다기보다 서버에 처리를 요청하는 경우에도 POST가 사용됩니다.

PUT: 리소스 전체 수정

PUT은 특정 리소스를 전체적으로 대체하거나 수정할 때 사용합니다.

예를 들어 1번 게시글 전체를 수정한다면 다음처럼 표현할 수 있습니다.

PUT /posts/1
Content-Type: application/json

{
  "title": "수정된 제목",
  "content": "수정된 본문입니다."
}

PUT은 보통 “이 리소스를 요청 본문의 내용으로 대체한다”는 의미에 가깝습니다.

따라서 일부 필드만 수정하는 경우에는 PATCH가 더 자연스러운 경우가 많습니다.

예를 들어 게시글에는 title, content, summary, is_public 같은 필드가 있는데, PUT 요청에서 일부 필드가 빠지면 서버가 이를 어떻게 처리할지 명확히 정해야 합니다.

PUT
→ 리소스 전체를 교체하는 의미에 가까움

PATCH: 리소스 일부 수정

PATCH는 리소스의 일부를 수정할 때 사용합니다.

예를 들어 게시글 제목만 수정하고 싶다면 다음처럼 요청할 수 있습니다.

PATCH /posts/1
Content-Type: application/json

{
  "title": "새 제목"
}

이 경우 서버는 title만 변경하고, 다른 필드는 그대로 유지할 수 있습니다.

PATCH는 다음 상황에 자주 사용됩니다.

게시글 제목만 수정
사용자 프로필 일부 수정
주문 상태 변경
공개 여부 변경
비밀번호 변경
알림 설정 일부 변경

예시는 다음과 같습니다.

PATCH /users/10
PATCH /posts/1
PATCH /orders/100/status

실무에서는 PUT과 PATCH의 구분이 팀이나 API 스타일에 따라 조금 다를 수 있습니다.
중요한 것은 API 문서에서 “전체 수정인지, 일부 수정인지”를 명확히 정하는 것입니다.

DELETE: 리소스 삭제

DELETE는 리소스를 삭제할 때 사용합니다.

예를 들어 1번 게시글을 삭제하려면 다음처럼 요청할 수 있습니다.

DELETE /posts/1

삭제에 성공했을 때는 응답 본문 없이 204 No Content를 반환하는 경우가 많습니다.

HTTP/1.1 204 No Content

또는 삭제된 리소스 정보를 반환할 수도 있습니다.

HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 1,
  "deleted": true
}

삭제 API를 설계할 때는 실제 삭제인지, soft delete인지도 고려해야 합니다.

실제 삭제
→ DB에서 행을 제거

soft delete
→ deleted_at 값만 기록하고 조회 대상에서 제외

서비스 요구사항에 따라 삭제 정책을 명확히 정해야 합니다.

HTTP 메서드별 역할 비교

REST API에서는 같은 URL이라도 HTTP 메서드에 따라 의미가 달라질 수 있습니다.

예를 들어 /posts와 /posts/1을 기준으로 보면 다음처럼 설계할 수 있습니다.

메서드	URL	의미
GET	/posts	게시글 목록 조회
POST	/posts	게시글 생성
GET	/posts/1	1번 게시글 조회
PUT	/posts/1	1번 게시글 전체 수정
PATCH	/posts/1	1번 게시글 일부 수정
DELETE	/posts/1	1번 게시글 삭제

핵심은 URL에 동사를 넣기보다, HTTP 메서드로 행동을 표현하는 것입니다.

좋은 예
GET /posts
POST /posts
DELETE /posts/1

아쉬운 예
GET /getPosts
POST /createPost
POST /deletePost

물론 모든 API를 완벽한 REST 스타일로 만들 필요는 없습니다.
하지만 리소스와 HTTP 메서드의 역할을 구분하면 API가 훨씬 예측 가능해집니다.

상태 코드는 왜 필요할까?

HTTP 응답에는 상태 코드가 포함됩니다.

상태 코드는 요청이 성공했는지, 실패했다면 어떤 종류의 실패인지 알려줍니다.

예를 들어 클라이언트가 게시글을 요청했는데 정상적으로 조회되었다면 서버는 200 OK를 반환할 수 있습니다.

HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 1,
  "title": "REST API 이해하기"
}

상태 코드는 클라이언트가 응답을 어떻게 처리할지 판단하는 기준이 됩니다.

200번대
→ 성공

400번대
→ 클라이언트 요청 문제

500번대
→ 서버 내부 문제

상태 코드를 적절히 사용하면 API 사용자와 프론트엔드 개발자가 문제를 더 쉽게 파악할 수 있습니다.

자주 사용하는 2xx 성공 상태 코드

2xx 상태 코드는 요청이 성공했음을 나타냅니다.

200 OK

가장 일반적인 성공 응답입니다.

조회 요청이나 일반적인 성공 응답에 자주 사용합니다.

GET /posts/1
→ 200 OK

201 Created

새 리소스가 생성되었을 때 사용합니다.

POST /posts
→ 201 Created

204 No Content

요청은 성공했지만 응답 본문이 없을 때 사용합니다.

삭제 요청 성공 시 자주 사용됩니다.

DELETE /posts/1
→ 204 No Content

자주 사용하는 4xx 클라이언트 오류 상태 코드

4xx 상태 코드는 클라이언트 요청에 문제가 있음을 나타냅니다.

400 Bad Request

요청 형식이 잘못되었거나 필요한 값이 올바르지 않을 때 사용할 수 있습니다.

POST /posts

{
  "title": ""
}

예를 들어 제목이 필수인데 빈 문자열이 들어왔다면 400 Bad Request나 422 Unprocessable Content 같은 상태를 고려할 수 있습니다.

401 Unauthorized

인증이 필요한데 인증 정보가 없거나 유효하지 않을 때 사용합니다.

GET /me
Authorization: Bearer invalid-token

→ 401 Unauthorized

403 Forbidden

인증은 되었지만 해당 리소스에 접근할 권한이 없을 때 사용합니다.

DELETE /admin/users/1
→ 403 Forbidden

예를 들어 일반 사용자가 관리자 기능에 접근하려고 하면 403 Forbidden이 적절할 수 있습니다.

404 Not Found

요청한 리소스를 찾을 수 없을 때 사용합니다.

GET /posts/999999
→ 404 Not Found

409 Conflict

요청이 현재 리소스 상태와 충돌할 때 사용할 수 있습니다.

예를 들어 이미 사용 중인 이메일로 회원가입하려고 할 때 409 Conflict를 고려할 수 있습니다.

POST /users
→ 409 Conflict

자주 사용하는 5xx 서버 오류 상태 코드

5xx 상태 코드는 서버에서 요청을 처리하는 중 문제가 발생했음을 나타냅니다.

500 Internal Server Error

서버 내부에서 예상하지 못한 오류가 발생했을 때 사용합니다.

HTTP/1.1 500 Internal Server Error

502 Bad Gateway

게이트웨이나 프록시 서버가 뒤쪽 서버에서 잘못된 응답을 받았을 때 발생할 수 있습니다.

로드밸런서, 프록시, API 게이트웨이 환경에서 볼 수 있습니다.

503 Service Unavailable

서버가 일시적으로 요청을 처리할 수 없을 때 사용합니다.

예를 들어 서버 점검, 과부하, 일시적인 장애 상황에서 나타날 수 있습니다.

서버 오류는 클라이언트가 직접 고칠 수 없는 문제인 경우가 많습니다.
따라서 서버 쪽 로그와 모니터링을 통해 원인을 확인해야 합니다.

JSON 응답 구조

REST API에서는 응답 본문으로 JSON을 많이 사용합니다.

JSON은 JavaScript Object Notation의 약자이며, 사람이 읽기 쉽고 프로그램에서도 처리하기 쉬운 데이터 형식입니다.

예를 들어 게시글 상세 API 응답은 다음처럼 만들 수 있습니다.

{
  "id": 1,
  "title": "REST API 이해하기",
  "content": "REST API의 기본 개념을 정리합니다.",
  "author": {
    "id": 10,
    "name": "Kim"
  },
  "created_at": "2026-05-11T10:00:00Z"
}

목록 응답은 배열로 반환할 수 있습니다.

[
  {
    "id": 1,
    "title": "첫 번째 글"
  },
  {
    "id": 2,
    "title": "두 번째 글"
  }
]

또는 페이지네이션 정보를 함께 담기 위해 객체 형태로 감쌀 수도 있습니다.

{
  "count": 120,
  "next": "/posts?page=2",
  "previous": null,
  "results": [
    {
      "id": 1,
      "title": "첫 번째 글"
    },
    {
      "id": 2,
      "title": "두 번째 글"
    }
  ]
}

중요한 것은 응답 구조를 일관되게 유지하는 것입니다.

에러 응답도 일관성이 필요합니다

성공 응답만큼 중요한 것이 에러 응답입니다.

나쁜 에러 응답은 클라이언트가 문제를 이해하기 어렵게 만듭니다.

예를 들어 단순히 문자열만 반환하면 처리하기 불편할 수 있습니다.

"오류가 발생했습니다."

더 나은 방식은 에러 코드를 포함한 구조화된 응답입니다.

{
  "error": {
    "code": "INVALID_TITLE",
    "message": "제목은 비워둘 수 없습니다."
  }
}

필드별 검증 오류라면 다음처럼 표현할 수 있습니다.

{
  "errors": {
    "title": ["제목은 필수입니다."],
    "content": ["본문은 10자 이상이어야 합니다."]
  }
}

에러 응답을 설계할 때는 다음을 고려해야 합니다.

사람이 읽을 수 있는 메시지가 있는가?
클라이언트가 분기 처리할 수 있는 에러 코드가 있는가?
필드별 오류를 표현할 수 있는가?
민감한 서버 내부 정보가 노출되지 않는가?
같은 종류의 오류는 같은 구조로 반환되는가?

특히 서버 예외 메시지나 stack trace를 그대로 API 응답에 노출하면 보안상 위험할 수 있습니다.

URL 설계 기본 원칙

REST API에서 URL은 리소스를 표현해야 합니다.

가능하면 명사 중심으로 설계하는 것이 좋습니다.

좋은 예
/users
/users/1
/posts
/posts/1/comments

아쉬운 예
/getUsers
/createPost
/deleteComment

행동은 URL이 아니라 HTTP 메서드로 표현합니다.

GET /posts
POST /posts
PATCH /posts/1
DELETE /posts/1

리소스 간 관계는 중첩 URL로 표현할 수 있습니다.

GET /posts/1/comments
POST /posts/1/comments

다만 중첩이 너무 깊어지면 URL이 복잡해질 수 있습니다.

GET /users/1/posts/10/comments/5/replies/3

이런 경우에는 적절히 별도 리소스로 분리하는 것이 더 나을 수 있습니다.

GET /comments/5/replies
GET /replies/3

URL 설계에서 중요한 것은 예측 가능성과 일관성입니다.

쿼리 파라미터는 언제 사용할까?

쿼리 파라미터는 목록 조회에서 필터링, 검색, 정렬, 페이지네이션 등에 자주 사용됩니다.

예를 들어 게시글 목록에서 특정 카테고리만 보고 싶다면 다음처럼 요청할 수 있습니다.

GET /posts?category=django

검색어를 전달할 수도 있습니다.

GET /posts?search=cache

정렬 조건을 줄 수도 있습니다.

GET /posts?ordering=-created_at

페이지네이션에는 page, limit, offset 같은 파라미터를 사용할 수 있습니다.

GET /posts?page=2&page_size=20

또는 offset 기반으로 설계할 수도 있습니다.

GET /posts?limit=20&offset=40

쿼리 파라미터는 리소스 자체를 식별하기보다는, 리소스 목록을 어떤 방식으로 볼지 정하는 데 사용한다고 이해하면 좋습니다.

/posts/1
→ 특정 리소스

/posts?category=django
→ 게시글 목록을 필터링해서 조회

멱등성 이해하기

REST API를 공부하다 보면 멱등성(idempotency)이라는 단어를 만날 수 있습니다.

멱등성은 같은 요청을 여러 번 보내도 결과가 같아야 한다는 성질입니다.

예를 들어 다음 요청을 생각해보겠습니다.

DELETE /posts/1

처음 요청하면 1번 게시글이 삭제됩니다.
같은 요청을 다시 보내도 1번 게시글이 삭제된 상태라는 결과는 변하지 않습니다.

이런 요청은 멱등하다고 볼 수 있습니다.

GET도 일반적으로 멱등합니다.

GET /posts/1

같은 조회 요청을 여러 번 보내도 서버 데이터가 바뀌지 않아야 합니다.

반면 POST /orders는 보통 멱등하지 않을 수 있습니다.

POST /orders

같은 주문 생성 요청을 두 번 보내면 주문이 두 개 생성될 수 있기 때문입니다.

이런 이유로 결제나 주문 생성처럼 중복 요청이 위험한 API에서는 멱등성 키를 사용하기도 합니다.

POST /orders
Idempotency-Key: 7f3a0b9c-...

멱등성은 단순 이론이 아니라, 네트워크 재시도나 중복 요청 처리에서 중요한 개념입니다.

인증과 권한은 REST API에서 어떻게 다룰까?

REST API는 보통 인증이 필요한 요청과 그렇지 않은 요청이 섞여 있습니다.

예를 들어 게시글 목록 조회는 누구나 가능하지만, 게시글 작성은 로그인한 사용자만 가능할 수 있습니다.

GET /posts
→ 인증 없이 가능

POST /posts
→ 인증 필요

인증 정보는 보통 HTTP 헤더에 담아 보냅니다.

예를 들어 토큰 기반 인증에서는 다음처럼 Authorization 헤더를 사용할 수 있습니다.

GET /me
Authorization: Bearer eyJhbGciOi...

서버는 이 토큰을 확인해서 사용자가 누구인지 판단합니다.

인증과 인가는 구분해야 합니다.

인증
→ 당신이 누구인지 확인

인가
→ 당신이 이 작업을 할 권한이 있는지 확인

예를 들어 로그인한 사용자가 자신의 게시글을 수정하는 것은 허용할 수 있습니다.

PATCH /posts/1
Authorization: Bearer ...

하지만 다른 사용자의 게시글을 수정하려고 하면 서버는 403 Forbidden을 반환할 수 있습니다.

HTTP/1.1 403 Forbidden

REST API에서 인증과 권한 처리는 보안과 직접 연결되므로, 단순히 프론트엔드에서 버튼을 숨기는 것만으로는 충분하지 않습니다.
서버에서 반드시 권한을 확인해야 합니다.

REST API 문서화

API는 혼자 쓰는 코드가 아닙니다.

프론트엔드 개발자, 모바일 개발자, 백엔드 개발자, 외부 파트너가 함께 사용할 수 있습니다.

그래서 API 문서화가 중요합니다.

API 문서에는 보통 다음 내용이 포함됩니다.

요청 URL
HTTP 메서드
요청 헤더
요청 바디
응답 상태 코드
응답 JSON 예시
에러 응답 예시
인증 필요 여부
권한 조건
쿼리 파라미터 설명

예를 들어 게시글 생성 API 문서는 다음처럼 정리할 수 있습니다.

POST /posts

설명:
새 게시글을 생성합니다.

인증:
필요

요청 본문:
{
  "title": "string",
  "content": "string"
}

성공 응답:
201 Created

{
  "id": 1,
  "title": "string",
  "content": "string"
}

오류 응답:
400 Bad Request
401 Unauthorized

문서가 잘 되어 있으면 협업 비용이 줄어듭니다.

OpenAPI 또는 Swagger 같은 도구를 사용하면 API 문서를 더 체계적으로 관리할 수 있습니다.

REST API 설계 시 자주 하는 실수

1. URL에 동사를 너무 많이 넣는 경우

GET /getPosts
POST /createPost
POST /deletePost

REST API에서는 가능하면 URL은 리소스를 표현하고, 행동은 HTTP 메서드로 표현하는 것이 좋습니다.

GET /posts
POST /posts
DELETE /posts/1

2. 항상 200 OK만 반환하는 경우

요청이 실패했는데도 항상 200 OK를 반환하면 클라이언트가 문제를 판단하기 어렵습니다.

HTTP/1.1 200 OK

{
  "success": false,
  "message": "권한이 없습니다."
}

권한이 없는 상황이라면 403 Forbidden 같은 적절한 상태 코드를 사용하는 편이 좋습니다.

HTTP/1.1 403 Forbidden

3. 에러 응답 형식이 제각각인 경우

어떤 API는 message, 어떤 API는 error, 어떤 API는 문자열만 반환하면 클라이언트 처리가 복잡해집니다.

에러 응답 형식을 프로젝트 안에서 일관되게 유지하는 것이 좋습니다.

4. 인증과 권한을 프론트엔드에만 맡기는 경우

프론트엔드에서 버튼을 숨기는 것은 사용자 경험을 위한 처리입니다.

보안은 반드시 서버에서 확인해야 합니다.

사용자가 직접 API를 호출할 수 있기 때문에, 서버는 요청마다 인증과 권한을 검증해야 합니다.

5. 목록 API에 페이지네이션이 없는 경우

데이터가 적을 때는 전체 목록 반환이 괜찮아 보일 수 있습니다.

하지만 데이터가 많아지면 응답 속도가 느려지고 서버와 클라이언트 모두 부담이 커집니다.

목록 API에는 처음부터 페이지네이션을 고려하는 것이 좋습니다.

GET /posts?page=1&page_size=20

6. 민감한 정보를 응답에 포함하는 경우

API 응답에는 필요한 데이터만 포함해야 합니다.

예를 들어 사용자 정보를 반환할 때 비밀번호 해시, 내부 관리용 값, 토큰 같은 민감한 정보가 포함되지 않도록 주의해야 합니다.

{
  "id": 1,
  "email": "kim@example.com",
  "password": "..."
}

이런 응답은 피해야 합니다.

REST API를 공부할 때 추천하는 순서

REST API를 처음 공부한다면 다음 순서로 익히는 것이 좋습니다.

HTTP 요청과 응답 구조를 이해합니다.
URL, 메서드, 헤더, 바디의 역할을 익힙니다.
GET, POST, PUT, PATCH, DELETE 차이를 익힙니다.
2xx, 4xx, 5xx 상태 코드를 구분합니다.
JSON 요청과 응답 구조를 연습합니다.
URL 설계와 쿼리 파라미터 사용법을 익힙니다.
인증과 권한 흐름을 이해합니다.
페이지네이션, 정렬, 필터링을 설계해봅니다.
에러 응답 형식을 일관되게 설계합니다.
API 문서를 작성해봅니다.

처음부터 완벽한 REST 원칙을 모두 외우려고 하기보다, 클라이언트와 서버가 어떤 약속으로 데이터를 주고받는지 이해하는 것이 중요합니다.

정리

REST API는 HTTP를 기반으로 리소스를 조회하고, 생성하고, 수정하고, 삭제하는 방식으로 설계되는 API입니다.

핵심은 리소스를 URL로 표현하고, 행동을 HTTP 메서드로 표현하는 것입니다.

정리하면 다음과 같습니다.

API는 프로그램과 프로그램이 대화하기 위한 약속입니다.
REST API는 HTTP 기반으로 리소스를 다루는 API 설계 방식입니다.
URL은 리소스를 표현하고, HTTP 메서드는 행동을 표현합니다.
GET은 조회, POST는 생성, PUT은 전체 수정, PATCH는 일부 수정, DELETE는 삭제에 자주 사용됩니다.
상태 코드는 요청이 성공했는지, 실패했다면 어떤 종류의 실패인지 알려줍니다.
JSON은 REST API에서 요청과 응답 데이터를 표현하는 데 자주 사용됩니다.
에러 응답도 성공 응답만큼 일관성이 중요합니다.
목록 API에는 필터링, 정렬, 페이지네이션을 고려해야 합니다.
인증은 사용자가 누구인지 확인하는 것이고, 인가는 해당 작업을 할 권한이 있는지 확인하는 것입니다.
API 문서화는 협업 비용을 줄이는 데 중요합니다.

REST API는 백엔드 개발의 가장 기본적인 주제 중 하나입니다.
HTTP 메서드와 상태 코드, JSON 응답 구조를 이해하면 Django REST Framework, FastAPI, Express 같은 프레임워크를 배울 때도 훨씬 수월해집니다.

참고 링크

'개발 기초' 카테고리의 다른 글

CSRF 이해하기: 쿠키 기반 인증에서 왜 중요한 보안 개념일까? (0)	2026.05.21
CORS 이해하기: 프론트엔드와 백엔드가 다른 도메인일 때 생기는 문제 (0)	2026.05.19
파이썬 GIL 이해하기: 멀티스레딩이 항상 빨라지지 않는 이유 (0)	2026.05.11
Docker 이해하기: 이미지, 컨테이너, Dockerfile, Compose까지 (0)	2026.05.11
로드밸런서 이해하기: 서버 트래픽을 나누고 장애를 줄이는 방법 (0)	2026.05.11

최근에 올라온 글

TAG more

티스토리 뷰