[CS 면접 기본 - 웹의 시작 ] 6. REST API는 뭘까? 설계시 고려사항은?

 

REST API는 Representational State Transfer의 약자로, 웹 서비스 아키텍처 스타일 중 하나입니다. REST는 클라이언트와 서버 간의 통신을 간단하고 일관된 방식으로 설계하기 위해 만들어졌으며, 주로 HTTP 프로토콜을 사용하여 자원(Resource)을 정의하고, 이를 전송하는 방법을 규정합니다. REST API를 통해 애플리케이션은 서버의 자원을 생성, 읽기, 업데이트, 삭제(CRUD) 작업을 수행할 수 있습니다.

REST의 주요 특징

REST 아키텍처 스타일의 API는 몇 가지 주요 원칙과 특징을 따릅니다.

1. 자원의 표현(Resource)
   • REST에서는 서버의 자원(예: 사용자 정보, 게시물, 제품 등)을 URL을 통해 명확하게 식별합니다.
   • 각 자원은 고유한 URI(Uniform Resource Identifier)로 식별되며, 이 URI를 통해 자원을 요청하거나 조작할 수 있습니다. 예를 들어, /users라는 경로는 사용자 목록 자원을 나타낼 수 있습니다.
2. HTTP 메서드 사용
   • REST는 HTTP 메서드를 사용하여 자원에 대한 작업을 정의합니다. 각 메서드는 고유한 의미를 가지며, CRUD(Create, Read, Update, Delete) 작업을 나타냅니다.
     • GET: 서버에서 자원의 조회를 수행합니다.
     • POST: 서버에 새로운 자원을 생성합니다.
     • PUT: 기존 자원을 업데이트하거나 생성합니다.
     • DELETE: 서버에서 자원을 삭제합니다.
     • PATCH: 자원의 일부를 수정합니다.
3. 무상태성(Stateless)
   • REST API는 무상태성을 유지합니다. 즉, 각 요청은 서로 독립적이며, 서버는 이전 요청의 정보를 저장하지 않습니다. 클라이언트는 필요한 모든 정보를 요청에 포함시켜야 합니다.
   • 무상태성 덕분에 서버 확장성이 향상되며, 서버 간의 로드 밸런싱이 용이해집니다.
4. 표현의 일관성 (Uniform Interface)
   • REST는 클라이언트와 서버 간의 일관된 인터페이스를 정의하여, 모든 자원에 대해 동일한 방식으로 접근할 수 있도록 합니다.
   • 자원의 표현 방식(예: JSON, XML, HTML)을 통해 클라이언트와 서버 간의 데이터 교환이 이루어집니다. JSON은 경량 데이터 교환 포맷으로 인기가 많습니다.
5. 계층형 구조 (Layered System)
   • REST API는 클라이언트, 서버, 데이터베이스, 중개 서버 등의 계층을 구분할 수 있습니다. 이 구조는 클라이언트가 중간 서버나 캐시 서버를 통해 서버와 통신할 수 있도록 하여, 확장성과 보안을 높이는 데 도움을 줍니다.
6. 캐시 가능(Cacheable)
   • RESTful 웹 서비스는 응답 데이터를 캐시할 수 있도록 설계됩니다. 서버는 클라이언트가 데이터를 캐시할 수 있는지 여부를 응답 헤더에 포함시킬 수 있습니다.
   • 캐싱은 응답 시간을 단축하고, 서버의 부하를 줄이는 데 유용합니다.

REST API의 장점

• 간단하고 일관된 인터페이스: HTTP 표준을 사용하여 쉽고 일관된 API 설계가 가능합니다.
• 확장성: 서버가 상태를 저장하지 않기 때문에 로드 밸런싱이나 서버 확장에 용이합니다.
• 다양한 표현 형식: JSON, XML, HTML 등 다양한 형식의 데이터 전송을 지원하여 클라이언트와 서버 간의 호환성이 좋습니다.
• 재사용성: REST API의 일관된 설계 원칙 덕분에 기존의 자원 URI와 메서드를 재사용하기가 쉽습니다.

REST API의 단점

• 무상태성으로 인한 정보 중복: 클라이언트가 요청할 때마다 필요한 모든 정보를 보내야 하므로, 요청 크기가 커질 수 있습니다.
• 복잡한 관계형 데이터 처리에 어려움: 자원 간의 복잡한 관계를 표현하는 것이 제한적일 수 있습니다.
• HTTP의 한계: REST는 HTTP 프로토콜에 종속적이므로, 다른 통신 방식이 필요할 때는 REST로는 구현하기 어려운 경우가 있습니다.
  
  => REST API는 일반적인 웹 애플리케이션 개발에 적합하지만, 실시간 양방향 통신, 대용량 파일 전송, 복잡한 상태 관리, 다중 서비스 통신, 고도로 맞춤화된 데이터 요청과 같은 특정 상황에서는 적합하지 않을 수 있습니다.
  
  

REST API의 사용 사례

• 웹 애플리케이션 백엔드: REST API는 프론트엔드와 백엔드 간의 데이터 교환에 많이 사용됩니다. 예를 들어, SPA(Single Page Application)에서 비동기적으로 서버와 데이터를 주고받을 때 활용됩니다.
• 모바일 애플리케이션 서버 통신: 모바일 앱과 서버 간의 데이터 통신을 RESTful API를 통해 구현할 수 있습니다.
• 서드파티 API 제공: 여러 서비스(예: 소셜 로그인, 결제 서비스)는 REST API를 통해 외부 개발자에게 기능을 제공합니다.

결론

REST API는 간단하고 일관된 웹 서비스 설계 방식으로, HTTP 프로토콜을 사용하여 웹 애플리케이션 간의 데이터 통신을 효과적으로 처리할 수 있습니다. 이 방식은 현대 웹 개발에서 가장 널리 사용되는 API 설계 패턴 중 하나입니다.

REST API의 설계 고려사항 3가지

REST API 설계 시 고려해야 할 중요한 사항은 다음과 같습니다:

1. 명확한 자원(URL) 설계
   • 자원을 나타내는 URL은 직관적이고 의미를 명확하게 해야 합니다. URL은 리소스를 표현해야 하며, 행동(동사)이 아닌 명사를 사용하여 자원을 식별합니다.
   • 예: /users (사용자 목록), /users/123 (특정 사용자), /products/456 (특정 제품)처럼 일관된 네이밍 컨벤션을 유지합니다.
   • 복수형 명사를 사용하여 일관성을 유지하고, 자원 간의 계층 관계를 나타내기 위해 URL 경로를 설계합니다.
2. HTTP 메서드의 올바른 사용
   • REST API는 **HTTP 메서드(GET, POST, PUT, DELETE, PATCH)**를 사용하여 자원에 대한 작업을 정의합니다. 각각의 메서드는 고유한 의미를 가지며, 이 의미에 맞게 사용해야 합니다.
     • GET: 자원 조회 (읽기)
     • POST: 자원 생성
     • PUT: 자원의 전체 업데이트 (대체)
     • PATCH: 자원의 부분 업데이트
     • DELETE: 자원 삭제
   • 메서드의 목적에 맞게 사용함으로써 API의 일관성을 유지하고, 클라이언트가 예상 가능한 방식으로 동작하도록 만듭니다.
3. 상태 코드 및 응답 형식의 일관성
   • API는 HTTP 상태 코드를 사용하여 요청의 성공 여부를 나타내야 합니다. 클라이언트가 응답을 보고 요청이 성공했는지, 오류가 발생했는지 알 수 있어야 합니다.
     • 200 OK: 요청 성공
     • 201 Created: 자원 생성 성공
     • 400 Bad Request: 잘못된 요청
     • 404 Not Found: 자원이 없음
     • 500 Internal Server Error: 서버 오류
   • 응답 형식은 JSON 또는 XML 등의 일관된 포맷을 사용하고, 에러 메시지 및 메타데이터를 포함하여 클라이언트가 응답을 이해하고 처리할 수 있도록 합니다.

이 세 가지 고려사항을 준수하면, 일관되고 사용하기 쉬운 REST API를 설계할 수 있습니다.