REST API란? 개념부터 설계, 실무 적용, 면접 준비까지

이 글은 REST API에 대한 기본 개념은 물론이고, 실무에서 어떻게 활용되는지, 그리고 면접에서 어떤 질문이 나올 수 있는지를 상세히 설명한 글입니다. RESTful 설계 원칙부터 실전 예시, 보안 고려사항, 그리고 API 문서화까지 모두 포함하여 종합적으로 정리하였습니다.

---

REST API의 개념과 등장 배경

REST는 "Representational State Transfer"의 약자로, 자원을 이름으로 구분하여 해당 자원의 상태(정보)를 주고받는 모든 것을 의미합니다. REST API는 REST 아키텍처 스타일을 따르는 API입니다.

REST는 2000년에 **로이 필딩(Roy Fielding)**의 박사 논문에서 처음 소개되었습니다. 그 당시 웹이 커지면서, 다양한 시스템들이 서로 통신하기 위한 표준화된 방법이 필요했으며, REST는 이 요구를 충족하기 위한 가장 유연하고 확장성 있는 방식으로 주목받게 되었습니다.

---

REST API에서 말하는 ‘자원(Resource)’과 URI의 개념

REST에서 중요한 개념은 바로 **자원(Resource)**입니다. 자원은 사용자, 게시물, 상품 등 정보의 단위를 의미하며, 각각의 자원은 고유한 URI(Uniform Resource Identifier)를 가집니다.

예를 들어 `/users/1`은 ID가 1번인 유저 자원에 접근하는 URI입니다.

• `/users` → 사용자 목록
• `/users/1` → ID가 1인 사용자
• `/products/45` → ID가 45인 상품

즉, URI는 자원을 표현하고, HTTP Method는 자원에 대한 행위를 정의합니다.

---

HTTP 메소드와 REST의 관계

REST API는 HTTP 메소드를 활용하여 자원에 대한 행위를 정의합니다. 다음은 각 메소드의 의미와 예시입니다:

메소드	의미	예시
GET	자원 조회	GET `/users/1` → 유저 조회
POST	자원 생성	POST `/users` → 유저 생성
PUT	자원 전체 수정	PUT `/users/1` → 유저 전체 수정
PATCH	자원 부분 수정	PATCH `/users/1` → 일부 속성 수정
DELETE	자원 삭제	DELETE `/users/1` → 유저 삭제

---

REST API의 설계 원칙: RESTful이란 무엇인가?

REST API를 설계할 때 다음의 6가지 REST 제약 조건을 잘 따를수록 "RESTful하다"고 표현합니다.

1. 클라이언트-서버 구조
   사용자 인터페이스와 데이터 저장을 명확히 분리하여 독립적으로 발전 가능하게 합니다.
2. 무상태성(Stateless)
   각 요청은 독립적으로 처리되며, 서버는 이전 요청 상태를 기억하지 않습니다.
3. 캐시 처리 가능(Cacheable)
   응답 데이터에 캐시 가능 여부를 명시하여 성능 최적화를 도모합니다.
4. 계층화 시스템(Layered System)
   클라이언트는 중간 서버(게이트웨이, 로드 밸런서 등)를 인식하지 못하게 설계됩니다.
5. 인터페이스 일관성(Uniform Interface)
   URI 설계, HTTP 메소드 사용 등 API의 일관성을 유지해야 합니다.
6. 코드 온 디맨드(Optional)
   서버는 클라이언트에 스크립트 등을 전달하여 동적으로 기능을 확장할 수 있습니다. (자주 사용되진 않음)

---

REST API vs 기타 API 형식 (SOAP, GraphQL 등)

항목	REST API	SOAP API	GraphQL
프로토콜	HTTP	SOAP (자체 프로토콜)	HTTP
유연성	높음	낮음	매우 높음
사용 난이도	보통	높음	높음
데이터 형식	주로 JSON	XML	JSON
자원 요청 방식	엔드포인트별 명확	복잡	단일 엔드포인트, 요청 지정 가능

---

실무에서 REST API는 어떻게 활용되는가?

실제 현업에서는 REST API를 다음과 같은 다양한 영역에서 사용합니다:

1. 프론트엔드와 백엔드 통신
   • Vue, React 등의 프론트에서 Axios 또는 Fetch API를 이용해 REST API에 요청을 보냅니다.
2. 모바일 앱과 서버 간 데이터 통신
   • iOS/Android 앱이 서버와 데이터를 주고받을 때 REST API를 사용합니다.
3. 서버 간 통신 (B2B, Microservice 등)
   • 여러 마이크로서비스 간 통신 시 REST API를 통해 독립적이고 확장 가능한 시스템을 구성합니다.

---

REST API 설계 시 반드시 고려해야 할 사항

• URI는 명사형, 소문자 사용
  예: `/users`, `/products/123`
• 버전 관리 필수
  예: `/api/v1/users`, `/api/v2/users`
• 응답 코드 정확히 사용
  • `200 OK`: 성공
  • `201 Created`: 생성 성공
  • `204 No Content`: 삭제 성공
  • `400 Bad Request`: 잘못된 요청
  • `401 Unauthorized`: 인증 실패
  • `404 Not Found`: 자원 없음
  • `500 Internal Server Error`: 서버 오류
• 에러 메시지 명확하게 리턴
  JSON 형태로 에러 원인을 설명하는 메시지와 함께 반환합니다.

---

REST API 보안 고려 사항

REST API는 웹 상에서 노출되기 때문에 보안이 중요합니다.

• HTTPS 사용 필수
• 토큰 기반 인증 (JWT, OAuth 2.0) 사용
• Rate Limiting
• 입력 값 검증 및 XSS/SQL Injection 방지
• CORS 설정 적절히

---

REST API의 문서화 및 테스트 도구

REST API는 명확한 문서화가 중요합니다. 다음과 같은 도구들을 사용합니다:

• Swagger / OpenAPI: API 스펙을 문서화하고 테스트 가능하게 만듭니다.
• Postman: API 테스트, 자동화 스크립트 작성 등
• Insomnia: 직관적인 API 테스트 도구

---

REST API 관련 면접 질문 예시

1. REST와 RESTful의 차이는 무엇인가요?
2. PUT과 PATCH의 차이를 설명해보세요.
3. REST API 설계 시 고려할 점은 어떤 것이 있나요?
4. 상태 비저장성의 의미는 무엇인가요?
5. REST API에서 인증은 어떻게 처리하나요?
6. REST API의 캐시 전략은 어떻게 구성하나요?

---

REST API 활용 시 추가로 고려할 고급 주제

• HATEOAS (Hypermedia as the Engine of Application State)
  → 클라이언트가 서버 응답 내 링크 정보를 통해 다음 행동을 유도받도록 설계
• Rate Limiting / Throttling
  → 대규모 API 트래픽을 제어하여 서버 과부하 방지
• API Gateway 도입
  → 마이크로서비스 구조에서 REST API 통합 지점을 구성 (Ex: Kong, AWS API Gateway)
• 동기 vs 비동기 API 설계 전략

---

정리

• REST API는 HTTP 기반의 아키텍처 스타일로, 자원 중심의 통신 방식을 제공합니다.
• HTTP 메소드와 URI를 조합하여 자원의 행위를 표현합니다.
• RESTful한 API를 설계하기 위해 6가지 제약 조건을 따릅니다.
• 실무에서는 프론트와 백, 앱-서버, 마이크로서비스 간 통신 등에 광범위하게 활용됩니다.
• Swagger나 Postman과 같은 도구를 사용하여 문서화와 테스트를 수행합니다.
• 보안을 위해 HTTPS, 토큰 인증, CORS 설정 등을 신중히 고려해야 합니다.
• 면접에서도 REST API의 원칙, 메소드 차이, 설계 방식, 보안 등을 주제로 자주 출제됩니다.