일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- elasticsearch
- Django
- intervals
- Service
- ebs
- POD
- kernel
- terraform
- 자바스크립트
- asyncio
- asgi
- IAM
- docker
- dockerfile
- K8S
- AWS
- Deployment
- FastAPI
- ansible
- Kubernetes
- EC2
- leetcode
- IAC
- github
- Python
- event loop
- YAML
- EKS
- 쿠버네티스
- WSGI
- Today
- Total
궁금한게 많은 개발자 노트
API 디자인 (REST, GraphQL, gRPC, WebSocket) 본문
API 디자인은 소프트웨어 애플리케이션 간의 통신을 가능하게 하는 구조를 설계하는 과정을 의미합니다.
API는 애플리케이션 프로그래밍 인터페이스 (Application Programming Interface)의 약자로, 서로 다른 소프트웨어 시스템이 상호작용할 수 있게 해주는 인터페이스입니다. API 디자인에는 REST, GraphQL, gRPC, WebSocket등 여러 종류가 있으며 각 디자인 방식은 성격과 용도에 따라 차이가 있습니다.
REST (Representational State Transfer) API
REST API는 HTTP 프로토콜을 기반으로 한 아키텍처 스타일로, 리소스(데이터)를 URI로 식별하고
이를 HTTP 메소드(GET, POST, PUT, DELETE 등)를 사용하여 조작합니다.
특징:
- 리소스 지향적
- 상태 비저장성(stateless)
- 표준 HTTP 메소드를 활용
- JSON, XML 등 다양한 포맷을 지원
주로 쓰이는 서비스:
- 대부분의 웹 애플리케이션, 모바일 애플리케이션에서 사용
- 트위터, 구글, 페이스북 등의 공용 API
장점:
- 단순성: HTTP 프로토콜을 사용하기 때문에 별도의 통신 프로토콜을 정의할 필요가 없음.
- 범용성: 대부분의 프로그래밍 언어에서 지원.
- 확장성: 여러 리소스를 명확히 정의할 수 있어 확장이 용이함.
단점:
- 비효율성: 클라이언트가 여러 리소스를 얻기 위해 여러 번의 요청을 보내야 할 수 있음.
- 상태 유지의 어려움: 상태 비저장성 때문에 클라이언트가 상태를 관리해야 함.
GraphQL API
GraphQL은 페이스북에서 개발한 쿼리 언어로, 클라이언트가 원하는 데이터를 명확히 지정하여 요청할 수 있도록 설계되었습니다. 클라이언트는 필요한 데이터만 요청할 수 있기 때문에 불필요한 데이터의 과다 전송을 줄일 수 있습니다.
특징:
- 클라이언트가 필요한 데이터만 요청 가능
- 하나의 엔드포인트에서 모든 쿼리 처리
- 명확한 스키마 정의
주로 쓰이는 서비스:
- 페이스북, GitHub, 쇼피파이(Shopify) 등 복잡한 데이터 모델을 다루는 서비스에서 사용
장점:
- 유연성: 클라이언트가 정확히 필요한 데이터만 요청할 수 있음.
- 효율성: REST의 경우 여러 엔드포인트에 요청해야 하는 데이터를 한 번의 요청으로 모두 가져올 수 있음.
- 강력한 스키마: 명확한 데이터 모델을 제공하여 API 변경 사항을 쉽게 추적하고 관리할 수 있음.
단점:
- 복잡성: 서버 측에서는 GraphQL 스키마와 리졸버(resolver)를 설계하는 과정이 REST보다 복잡함.
- 캐싱 어려움: REST에서는 URL 기반으로 캐싱이 용이한 반면, GraphQL은 요청 내용에 따라 다르므로 캐싱이 어려울 수 있음.
gRPC (Google Remote Procedure Call)
gRPC는 구글에서 개발한 프레임워크로, HTTP/2 프로토콜을 사용하며 주로 마이크로서비스 간의 통신에서 사용됩니다. 주고받는 메시지를 Protobuf(Protocol Buffers) 형식으로 직렬화하여 효율적으로 데이터를 전송합니다.
특징:
- HTTP/2 기반, 스트리밍 지원
- Protobuf를 통한 효율적 직렬화
- 양방향 스트리밍 지원
- 서비스 정의 인터페이스(SDI)를 사용한 클라이언트/서버 간 명세화
주로 쓰이는 서비스:
- 구글 클라우드 서비스, 넷플릭스, 드롭박스 등 대규모 분산 시스템에서 사용
- 고성능을 요구하는 마이크로서비스 아키텍처에서 주로 사용
장점:
- 고성능: HTTP/2와 Protobuf 덕분에 속도와 네트워크 대역폭 사용이 최적화됨.
- 스트리밍: 클라이언트와 서버 간에 실시간 데이터 스트리밍이 가능함.
- 다양한 언어 지원: 다양한 언어에서 사용 가능.
단점:
- 복잡성: REST에 비해 설계와 구현이 복잡함.
- 디버깅 어려움: Protobuf는 이진 형식이기 때문에 디버깅이 어렵고, HTTP/2 역시 디버깅 도구가 제한적임.
- 브라우저 지원 미흡: 웹 브라우저 환경에서의 직접적인 사용은 제한적이며, 주로 백엔드 서비스 간의 통신에서 사용됨.
WebSocket API
WebSocket은 서버와 클라이언트 간의 양방향 통신을 가능하게 하는 프로토콜로, 실시간 데이터 전송에 주로 사용됩니다.
HTTP 연결을 업그레이드하여 WebSocket 연결을 시작하며, 연결이 유지된 동안 양방향 통신이 가능합니다.
특징:
- 풀 이중 통신 가능
- 실시간 데이터 전송에 적합
- 지속적인 연결 유지
주로 쓰이는 서비스:
- 실시간 채팅 애플리케이션, 온라인 게임, 주식 트레이딩 플랫폼, 스트리밍 서비스
장점:
- 실시간성: 서버와 클라이언트 간의 빠르고 지속적인 양방향 통신이 가능함.
- 효율성: 연결이 유지되는 동안 지속적으로 데이터를 주고받을 수 있어 실시간 응답이 필요할 때 유리함.
단점:
- 복잡성: 연결 관리, 오류 처리, 보안 등이 복잡할 수 있음.
- 리소스 사용량: 연결이 지속적으로 유지되기 때문에 리소스 소비가 많을 수 있음.
비교 요약:
API 디자인 | 특징 | 주로 쓰이는 서비스 | 장점 | 단점 |
REST | HTTP 기반 리소스 지향, 상태 비저장성 | 웹 및 모바일 앱 | 단순하고 범용적, 확장성 높음 | 여러 요청 필요, 상태 유지 어려움 |
GraphQL | 쿼리 언어를 통한 유연한 데이터 요청 | 복잡한 데이터 구조를 다루는 애플리케이션 | 클라이언트가 필요한 데이터만 요청, 효율성 높음 | 서버 측 구현 복잡, 캐싱 어려움 |
gRPC | HTTP/2, Protobuf 기반, 고성능 RPC 통신 | 마이크로서비스, 분산 시스템 | 고성능, 스트리밍 지원, 다양한 언어 지원 | 구현 복잡, 디버깅 어려움, 브라우저 지원 미흡 |
WebSocket | 실시간 양방향 통신 지원 | 실시간 애플리케이션, 게임, 스트리밍 | 실시간 데이터 전송 가능, 연결 유지 | 복잡한 연결 관리, 리소스 사용량 높음 |
각 API 디자인은 그 자체로 장단점이 있으며, 사용하는 서비스의 성격에 따라 적합한 API 디자인을 선택하는 것이 중요합니다. REST는 전통적인 웹 서비스에 널리 사용되며, GraphQL은 복잡한 쿼리와 효율성을 필요로 하는 서비스에 적합하고, gRPC는 성능이 중요한 마이크로서비스 환경에서 주로 사용됩니다. WebSocket은 실시간 통신이 중요한 애플리케이션에 최적화되어 있습니다.
[ REST API ]
REST API는 가장 많이 사용되는 API 패턴 중 하나로 HTTP 프로토콜을 기반으로, 리소스를 URI로 구분하고 HTTP 메소드로 리소스를 조작합니다. 리소스 지향적이며 stateless한 특징을 갖고 있고, XML, JSON등 다양한 포맷을 지원합니다. 이러한 특징을 가지고 있기에 모바일이나 웹 애플리케이션에 많이 사용됩니다.
장점으로는 범용 HTTP 프로토콜을 사용하기에 별도의 통신 프로토콜 정의가 필요하지 않으며, 여러 리소스를 명확히 정의할 수 있어 확장에 용이합니다. 단점으로는 여러 리소스를 얻기 위해 여러번 호출해야하는 번거로움이 있으며, stateless특징으로 상태유지를 위해서는 client가 상태를 관리해야 합니다.
[ GraphQL API ]
페이스북에서 개발한 쿼리 언어로 원하는 데이터를 명확히 지정하여 요청할 수 있도록 설계되었습니다. 클라이언트는 필요한 데이터만 요청할 수 있기에 불필요한 데이터 과다 전송을 줄일 수 있습니다. 이에 복잡한 데이터 모델을 다루는 서비스에서 주로 사용됩니다.
장점으로는 정확히 필요한 데이터만 요청할 수 있고, REST의 경우 여러 엔트포인트에 요청해야 하는 데이터를 한번의 요청으로 모두 가져올 수 있습니다. 또한 강력한 데이터 스키마를 기반으로 API변경 사항을 쉽게 추적하고 관리할 수 있습니다.
단점도 있습니다. 서버 측에서 GraphQL 스키마와 Resolver를 설계하는 과정이 REST보다 복잡하며 REST에서는 URL단위 캐싱이 용이하지만, GraphQL은 요청 내용에 따라 다르므로 캐싱이 어렵습니다.
[ gRPC API ]
gRPC는 구글에서 개발한 프레임워크로 HTTP/2 프로토콜을 사용하며 주로 마이크로서비스 간의 통신에 사용됩니다.
주고받는 메시지를 Protobuf형식으로 직렬화하여 효율적으로 데이터를 전송합니다.
특징으로는 HTTP/2기반 양방향 스트리밍을 지원하며 서비스 정의 인터페이스(SDI)를 사용한 클라이언트 서버 간 명세화를 통해 일치하는 경우만 통신이 진행됩니다. 양방향 실시간 스트리밍이 가능하므로 고성능을 요구하는 MSA에서 주로 사용됩니다.
장점으로는 위에서 언급한 고성능, 양방향 스트리밍이 있으며 다양한 언어에서 사용이 가능합니다.
단점으로는 REST에 비해 설계와 구현이 복잡하며, 이진 형식으로 통신, HTTP/2를 사용하므로 디버깅이 복잡합니다. 또한, 브라우저에서 직접적인 사용은 제한적이며 MSA에서만 활발히 사용됩니다.
[ Websocket ]
서버와 클라이언트 간의 양방향 통신을 가능하게 하는 프로토콜로 실시간 데이터 전송에 주로 사용됩니다.
HTTP연결을 업그레이드하여 Websocket 연결을 시작하며 연결이 유지된 동안 양방향 통신이 가능합니다.
실시간 데이터 전송에 적합하며, 지속적인 연결이 필요하다는 특징이 있어 실시간 채팅이나 주식 트레이딩 플랫폼, 스트리밍 서비스에 주로 사용됩니다.
장점으로는 실시간성과 연결 유지되는 동안 지속적으로 데이터를 주고 받을 수 있기에 효율적입니다.
단점으로는 연결 관리, 오류 처리, 보안 등이 복잡하며, 연결 지속 유지를 위해 리소스 소비가 많을 수 있습니다.
'Back End' 카테고리의 다른 글
[ Fluent Bit ] Backpressure 해결책 Buffering (0) | 2024.05.28 |
---|---|
[ FastAPI ] Streaming large size file using StreamingResponse (0) | 2024.04.22 |
[ Python] aiobotocore를 사용한 AWS S3와 연동 (0) | 2024.02.08 |
[ FastAPI ] 비동기 메커니즘 (0) | 2023.12.11 |
[ Database ] Elasticsearch vs RDBMS (0) | 2023.07.22 |