REST(Representational State Transfer)는 분산 시스템 설계를 위한 아키텍처 스타일입니다. 웹 기술과 HTTP 프로토콜을 사용하여 서버의 리소스와 서비스를 정의하고 액세스하는 방법을 제시합니다. REST의 핵심 개념은 리소스(자원)를 중심으로 한 통신입니다. 리소스는 URI로 식별되며, 해당 리소스에 대한 행동은 HTTP 메서드(GET, POST, PUT, DELETE 등)를 통해 표현됩니다.
REST의 주요 특징
- Stateless Communication (무상태 통신): 각 요청 간에 클라이언트의 상태 정보가 저장되지 않습니다. 이로 인해 서버의 설계가 단순해지며 확장성이 높아집니다.
- Cacheable (캐시 가능): HTTP가 가진 캐싱 기능을 활용할 수 있어, 효율적인 데이터 전송이 가능해집니다.
- Uniform Interface (통일된 인터페이스): 애플리케이션과 분리된 통일된 인터페이스를 통해 상호작용합니다.
- Layered System (계층화 시스템): 클라이언트는 종단 서버와 직접 통신하는지, 중간에 다른 중개 서버를 거치는지 알 수 없습니다. 이는 보안, 로드 밸런싱, 암호화 계층 등을 추가하기 용이하게 만듭니다.
HATEOAS (Hypermedia As The Engine Of Application State)
HATEOAS는 RESTful API 설계의 중요 원칙 중 하나로, 클라이언트가 서버와의 상호작용을 현재 리소스의 상태에 대한 하이퍼링크를 통해서만 진행할 수 있게 하는 방식입니다. 이는 API의 유연성을 증가시키고, API 변화에 대한 클라이언트의 의존도를 감소시킵니다.
REST의 단점
- 명확한 표준 부재: REST는 아키텍처 스타일이므로, 구현에 있어서 명확한 표준이 없습니다. 이로 인해 "RESTful"이라고 주장하는 서비스 사이에 일관성이 부족할 수 있습니다.
- 복잡한 API 구현: RESTful 원칙을 완전히 준수하는 API를 설계하고 구현하는 것은 복잡할 수 있으며, 특히 HATEOAS와 같은 원칙은 구현 난이도가 높습니다.
REST는 그 유연성과 HTTP와의 밀접한 통합으로 인해 널리 사용되고 있습니다. 하지만 API를 설계할 때는 REST의 원칙을 충실히 따르려는 노력과 함께, 실제 애플리케이션의 요구 사항과 잘 맞는지를 고려해야 합니다.
예시
이해를 돕기 위해 REST API의 특징과 단점을 구체적인 예시와 함께 살펴보겠습니다.
REST API의 특징 예시
Stateless Communication (무상태 통신)
- 예시: 사용자가 웹 애플리케이션에서 로그인을 하여 글을 작성하는 경우, 각 HTTP 요청(로그인, 글 작성 등)은 독립적으로 처리됩니다. 서버는 클라이언트의 이전 상태를 기억하지 않으며, 각 요청은 필요한 모든 정보(예: 사용자 인증 토큰)를 포함해야 합니다.
Cacheable (캐시 가능)
- 예시: 웹 서비스가 날씨 정보를 제공하는 경우, 해당 정보는 변하지 않는 동안 여러 클라이언트 요청에 대해 캐시될 수 있습니다. 이를 통해 서버의 부하를 줄이고 응답 속도를 높일 수 있습니다.
Uniform Interface (통일된 인터페이스)
- 예시: 모든 리소스에 대한 액세스는 HTTP 표준 메서드(GET, POST, PUT, DELETE 등)를 사용하여 이루어집니다. 예를 들어, 모든 리소스 조회는 GET 요청을 통해, 리소스 생성은 POST 요청을 통해 수행됩니다.
Layered System (계층화 시스템)
- 예시: 클라이언트가 REST API를 호출할 때, 요청은 여러 네트워크 계층(예: 로드 밸런서, 보안 계층)을 거쳐 서버에 도달합니다. 클라이언트는 이러한 내부 구조를 모르며, 단지 API 엔드포인트에 요청을 보내고 응답을 받는 것에만 집중합니다.
REST API의 단점 예시
명확한 표준 부재
- 예시: REST는 규칙보다는 가이드라인을 제공합니다. 따라서, 다른 팀이나 조직에서 개발된 RESTful 서비스 간에 일관성이 부족할 수 있습니다. 예를 들어, 한 서비스에서는 리소스 삭제 후 HTTP 200(OK) 응답을 보내는 반면, 다른 서비스에서는 HTTP 204(No Content)를 사용할 수 있습니다.
복잡한 API 구현
- 예시: HATEOAS 원칙을 준수하려고 할 때, 응답에 각 리소스와 관련된 가능한 모든 액션을 포함하는 하이퍼링크를 동적으로 생성해야 합니다. 이는 개발자에게 추가적인 구현 복잡성을 초래하며, API의 변화 시 클라이언트와의 호환성 문제를 야기할 수 있습니다.
이와 같은 특징과 단점을 이해하고 고려함으로써, 개발자는 RESTful API를 더 효과적으로 설계하고 구현할 수 있습니다.
'여러가지 > 이것저것' 카테고리의 다른 글
OSI7계층과 TCP/IP 4계층 알아보기 (0) | 2024.03.18 |
---|---|
CORS란 무엇인가요? (0) | 2024.03.18 |
HTTP METHOD와 그 역할 (0) | 2024.03.18 |
GET과 POST의 차이점 (0) | 2024.03.18 |
HTTPS 공개키 암호화로 안전한 키 교환, 비밀키 암호화로 효율적인 데이터 통신을 보장/ 두 암호화 방식 사용 (0) | 2024.03.18 |