#1 REST API란?

 

현대 웹개발에서 REST API 사용은 필수라고 이야기합니다.

REST API는 무엇이고 왜 써야하는지 알아보겠습니다.

 

---

REST API(Representational State Transfer API)는 웹의 창시자 중 한 명인 로이 필딩(Roy Fielding) 박사가 2000년 그의 박사 학위 논문에서 제시한 인터넷 지향 소프트웨어 아키텍처 스타일이자 설계 원칙입니다.

쉽게 말해, 두 개의 서로 다른 소프트웨어가 웹의 통신 규약인 **HTTP(Hypertext Transfer Protocol)**를 활용하여 가장 효율적이고 직관적으로 데이터를 주고받을 수 있도록 정의한 약속이자 규칙 모음입니다.

REST API를 관통하는 핵심 구조와 핵심 원칙은 다음과 같이 정리할 수 있습니다.

---

1. REST API의 3대 핵심 구성 요소

REST 아키텍처는 자원(Resource)을 정의하고, 해당 자원에 대한 행위를 명확히 규정하며, 이를 표준화된 데이터 형식으로 표현하는 방식을 취합니다.

• 자원 (Resource - URI): 웹상에 존재하는 문서, 그림, 데이터 등 이름으로 구별할 수 있는 모든 논리적 실체를 뜻합니다. 이 자원들은 동사가 아닌 명사형 URI(Uniform Resource Identifier)로 유일하게 식별되어야 합니다 (예: /getUsers가 아닌 /users).
• 행위 (Verb - HTTP Method): 자원에 대해 수행할 행동(CRUD)을 나타냅니다. 자원 주소인 URI는 그대로 유지하되, HTTP 표준 메서드를 사용하여 행위를 명확히 구분합니다.
  • GET (Read): 자원 조회
  • POST (Create): 신규 자원 등록
  • PUT / PATCH (Update): 자원의 전체 교체 / 일부 수정
  • DELETE (Delete): 자원 삭제
• 표현 (Representation - JSON/XML): 클라이언트가 자원의 상태를 요청하면, 서버는 주로 가볍고 구조화된 형태인 JSON(JavaScript Object Notation) 등의 데이터 포맷으로 자원의 상태(표현)를 전달합니다.

---

2. REST 아키텍처의 6대 기본 조건 (Constraints)

시스템의 독립성과 대규모 확장성을 확보하기 위해 REST는 6가지 아키텍처 제약 조건을 지킬 것을 요구합니다.

1. 클라이언트-서버 구조 (Client-Server Architecture): 사용자 인터페이스(UI)를 담당하는 클라이언트와 데이터 처리를 담당하는 서버가 철저히 분리되어, 서로의 존재에 의존하지 않고 독립적으로 진화할 수 있게 합니다.
2. 무상태성 (Statelessness): 서버는 클라이언트의 상태(세션 등)를 기억하지 않습니다. 각 요청은 이전 요청과 독립적이며, 요청 자체에 처리에 필요한 모든 정보를 스스로 포함해야 하므로 서버 리소스를 빠르게 해제하고 확장을 용이하게 만듭니다.
3. 캐시 가능성 (Cacheability): 서버가 보낸 응답이 캐싱 가능한지 여부를 명시함으로써, 클라이언트나 중간 프록시가 동일 요청에 대해 응답을 재사용하여 네트워크 지연을 낮추고 성능을 극대화할 수 있게 돕습니다.
4. 계층화 시스템 (Layered System): 클라이언트는 최종 서버에 직접 연결되었는지, 혹은 프록시나 게이트웨이, 로드 밸런서 등 중간 계층을 거치고 있는지 알 수 없도록 구성되어 보안 및 확장성에 이점을 가집니다.
5. 코드 온 디맨드 (Code on Demand - 선택 사항): 필요한 경우 서버가 클라이언트로 실행 가능한 코드(예: 자바스크립트 스크립트)를 전송하여 클라이언트의 기능을 일시적으로 확장할 수 있습니다.
6. 일관된 인터페이스 (Uniform Interface - 가장 핵심): 자원이나 통신 프로토콜이 변하더라도 상호 작용 방식이 항상 일관되도록 보장합니다. 여기에는 자원의 URI 식별, 표현을 통한 조작 외에도 다음 두 가지가 포함됩니다.
   • 자기 서명적 메시지 (Self-descriptive): HTTP 헤더에 Content-Type: application/json과 같이 미디어 타입을 명시하여, 메시지 본문만 보고도 완전히 해석이 가능해야 합니다.
   • HATEOAS (Hypermedia As The Engine Of Application State): 홈페이지에서 링크를 클릭하며 페이지를 이동하듯, 서버의 응답 내에 다음에 취할 수 있는 행위와 관련된 하이퍼링크들을 동적으로 함께 제공해야 합니다.

---

3. RESTful API란?

로이 필딩 박사가 정의한 이 REST 아키텍처 원칙들을 완벽하게 준수하여 올바르게 설계된 API를 보고 'RESTful(레스트풀)하다' 또는 **'RESTful API'**라고 부릅니다.

현업에서는 설계의 편의성이나 개발 속도 때문에 메시지 자기 서명성(Self-descriptive)이나 HATEOAS 같은 규칙을 생략하고 단순히 URI와 HTTP 메서드만 매핑하여 사용하는 경우가 많지만, 엄밀한 의미의 RESTful을 달성하기 위해서는 모든 제약 조건을 만족하는 설계가 권장됩니다.

---

 

 

 

 

그럼 기존의 네트워크에서 데이터 처리방식과 REST API는 뭐가 다를까요?

 

---

탈락과 복잡성 속에서 탄생한 REST API는 기존의 전통적인 네트워크 데이터 처리 방식들과 뚜렷한 철학적, 기술적 차이를 지니고 있습니다.

기존의 대표적인 데이터 처리/통신 방식(SOAP, RPC, 세션 기반 방식)과 REST API가 어떻게 다른지, 그리고 현대 웹 개발에서 왜 REST API를 필수적으로 도입해야 하는지 핵심 차이점과 이점을 나누어 설명해 드립니다.

---

1. 기존 데이터 처리 방식과 REST API의 핵심 차이점

① 동사(행동) 중심 vs 명사(자원) 중심 (RPC 방식과의 차이)

• 기존 RPC(Remote Procedure Call) 방식: 네트워크 너머의 서버에 있는 특정 '함수나 프로시저'를 원격 호출하는 것에 집중합니다. 이로 인해 엔드포인트(URI)가 /getUserById, /deleteBook과 같이 동사(행동) 중심으로 설계되어 주소가 지저분해지고 일관성을 잃기 쉬웠습니다.
• REST API 방식: 모든 데이터와 대상을 단일한 **명사형 자원(Resource)**으로 식별합니다 (예: /users/{id}, /books/{id}). 자원의 조회, 생성, 수정, 삭제 등의 행위는 URI에 담지 않고, 오직 **HTTP 표준 메서드(GET, POST, PUT, DELETE)**라는 규격화된 동사를 결합하여 처리합니다.

② 복잡한 규격과 바디 vs 가볍고 직관적인 JSON (SOAP 방식과의 차이)

• 기존 SOAP(Simple Object Access Protocol) 방식: 초기 엔터프라이즈 환경을 지배했던 SOAP은 매우 엄격한 XML 기반의 메시지 포맷을 사용했습니다. 단순히 데이터 한 건을 가져오기 위해서도 엄청난 분량의 XML Wrapper 규격을 감싸서 통신해야 했기에 처리가 무겁고 개발 생산성이 떨어졌습니다.
• REST API 방식: 특정 프레임워크나 엄격한 프로토콜에 종속되지 않는 단순한 **디자인 원칙(스타일 가이드)**입니다. XML 구조의 오버헤드를 탈피하여 가볍고 구조화된 데이터 표현이 가능한 JSON(JavaScript Object Notation) 포맷을 주로 활용하므로 네트워크 대역폭이 절약되고 가독성이 극대화됩니다.

③ 상태 유지(Stateful) vs 무상태성(Stateless) (세션 기반 방식과의 차이)

• 기존 세션 기반 방식: 클라이언트의 로그인 상태나 이전 작업 맥락(Context)을 서버의 세션 메모리에 저장하여 관리합니다. 소규모일 때는 구현이 간편하지만, 서버가 늘어나는 분산 환경이나 마이크로서비스 아키텍처(MSA)에서는 각 서버가 세션을 동기화하거나 별도의 거대한 세션 저장소를 두어야 하므로 아키텍처 구조가 매우 무거워집니다.
• REST API 방식: 철저하게 **무상태성(Statelessness)**을 지향합니다. 서버는 클라이언트의 상태를 기억하지 않으며, 클라이언트가 보내는 모든 요청은 그 자체만으로 완전히 해석 가능한 독립적인 정보들을 포함해야 합니다. 서버는 요청을 신속히 처리한 후 즉시 시스템 자원을 해제하므로 확장성에 매우 유리합니다.

---

2. 왜 REST API를 써야 하는가? (도입 이유와 장점)

① 클라이언트와 서버의 철저한 디커플링 및 독립적 진화

REST 아키텍처는 사용자 인터페이스(UI)를 담당하는 클라이언트와 데이터 가공 및 영속성을 담당하는 서버의 역할을 완벽하게 분리합니다. 이 separation of concerns(관심사 분리) 원칙 덕분에, 서버 내부의 데이터베이스 구조나 소스코드가 대대적으로 변경되거나 심지어 백엔드 언어를 아예 바꾸더라도 클라이언트 코드를 일일이 수정하여 강제 업데이트할 필요가 없습니다.

② 무상태성을 통한 대규모 확장성 (Scalability)

서버에 클라이언트의 상태를 저장하지 않기 때문에, 트래픽이 폭증할 때 동일한 서버를 여러 대 확장(스케일 아웃)하여 로드 밸런서 뒤에 배치하기가 매우 쉬워집니다. 특정 서버 하나가 다운되더라도 클라이언트의 요청은 상태 정보를 모두 품고 있으므로, 살아있는 다른 어떤 서버로 요청이 전달되더라도 중단 없이 처리를 이어나갈 수 있습니다.

③ 웹 표준 캐싱(Cacheability)을 공짜로 활용 가능

REST API는 웹의 근간 프로토콜인 HTTP를 가공하지 않고 본래의 설계 의도대로 완벽히 이용합니다. 따라서 이미 인터넷 망에 널리 깔려 있는 브라우저 캐시, 프록시 서버, CDN(콘텐츠 전송 네트워크) 등의 캐싱 메커니즘을 그대로 적용할 수 있어, 서버의 원천 데이터베이스를 매번 조회하지 않고도 전 세계 사용자에게 매우 빠른 응답 속도를 보장합니다.

④ API의 직관성과 예측 가능성 (Predictability)

일관된 인터페이스 규칙(Uniform Interface)을 따르기 때문에, URI 경로와 HTTP 메서드 조합만 보고도 "이 요청이 어떤 자원을 어떻게 가공하려는지" 개발자가 직관적으로 예측할 수 있습니다. 복잡한 전용 API 명세서를 종일 분석하지 않아도 다른 플랫폼 간의 상호 운용성이 확보되며 협업 비용이 획기적으로 줄어듭니다.

---

요약하자면, REST API는 기술적 제약이라기보다 **"웹(Web)이 가진 본래의 유연함과 성능 잠재력을 훼손하지 않으면서 기계들이 대화하게 만들자"**는 피땀 어린 노력 끝에 정립된 가장 표준적이고 확장성 높은 웹의 통신 약속입니다.

---

 

 

https://youtu.be/5Z0PI5j_kxs?si=XURX-yJMJhKaBKLK