4만명의 개발자 대상 조사를 통해 정리한 API 프로토콜 트렌드와 장/단점

• Postman이 4만명의 개발자 대상 조사를 통해 정리한 API 프로토콜 트렌드와 장/단점
• REST, WebHooks, GraphQL, SOAP, WebSocket, gRPC 등

 

#REST

• 아직 가장 널리 사용. 지난 2년간 92% 에서 86%로 감소
• 단순성, 확장성 및 웹 서비스와의 통합 용이성
• REST의 장점
• 단순성 및 표준화: 표준 HTTP 방법을 이용하여 이미 HTTP에 익숙한 개발자가 쉽게 채택가능. 단순성은 신속한 학습과 통합을 촉진
• 확장성: REST의 상태 비저장 특성으로 인해 서버는 요청 간에 세션 데이터를 저장할 필요가 없음. 공유 서버 없이 인스턴스를 추가하여 수평적 확장을 용이하게 함
• 성능: 상태 비저장 및 캐시 가능한 응답은 실행 속도를 높이고 요청 수를 줄여줌
• 모듈성: RESTful 서비스는 모듈식 구성 요소로 개발될 수 있음. 독립적인 업데이트를 가능하게 하고 유지 관리성을 향상시킴
• 플랫폼에 구애받지 않음: 다양한 클라이언트로 사용가능. 상호 운용성이 시스템 전반에 걸쳐 API 통합을 촉진
• 성숙한 도구 및 커뮤니티 지원: 도구, 라이브러리, 모범 사례, 문제 해결 지침 및 커뮤니티 리소스가 많음
• REST의 과제
• 오버-펫칭 & 언더-펫칭: 클라이언트가 자료의 일부만 필요할수 있어서 데이터를 많이 가져오거나 적게 가져올 수 잇음. 이로 인해 성능 문제가 발생하고 대역폭이 낭비 될 수 잇음
• 여러번의 인터페이스: 관련 데이터를 검색하려면 여러 요청이 필요할 수 있으며 이로 인해 대기 시간이 늘어남. 이러한 호출의 연속으로 인해 애플리케이션이 확장되면서 문제가 됨
• 버전 관리 문제: REST API의 새 버전을 만드는 것은 번거로울 수 있으며, 특히 데이터 구조나 서비스 기능이 변경되는 경우 더욱 그러함. 이로 인해 이전 버전과의 호환성 문제가 발생하는 경우가 많음
• 무상태 오버헤드: 무상태는 확장성을 지원하지만 모든 요청에 ​​필요한 모든 컨텍스트를 제공해야 함을 의미하기도 함. 특히 클라이언트가 대량의 반복 데이터를 전송해야 하는 경우 오버헤드를 초래할 수 있음
• 실시간 기능 부족: REST는 채팅이나 라이브 피드와 같은 실시간 앱에 최적화되어 있지 않음. WebSocket과 SSE가 이러한 사용 사례에 더 적합

​

#WebHooks

• 웹훅은 소스 애플리케이션의 이벤트에 의해 트리거되는 사용자 정의 HTTP 콜백
• 이벤트가 발생하면 소스 애플리케이션은 대상 애플리케이션이 지정한 URI로 HTTP 요청(일반적으로 POST)을 보내며, 이를 통해 반복적인 폴링 없이 거의 실시간 이벤트 기반 통신이 가능
• 웹훅은 점점 인기를 얻고 있으며 개발자의 36%가 다양한 시스템 간의 원활한 통합을 위해 사용중
• WebHooks의 장점
• 실시간 통신: 웹훅으로 실시간 데이터 전송이 가능. 이벤트가 발생하면 해당 데이터가 전송되어 시스템 간 최신 동기화가 보장
• 효율성: 웹훅은 리소스 집약적인 폴링을 제거하여 컴퓨팅 성능과 대역폭을 절약
• 유연성: 웹훅은 특정 이벤트에 응답하도록 구성할 수 있으므로 한 애플리케이션의 어떤 작업이나 트리거가 다른 애플리케이션으로 데이터를 보낼지 사용자 정의할 수 있음
• 단순화된 통합: HTTP 방법을 사용하면 대부분의 애플리케이션에서 쉽게 사용할 수 있음
• 분리된 아키텍처 지원: 웹훅은 이벤트를 기반으로 작동하므로 자연스럽게 이벤트 중심 또는 분리된 아키텍처를 지원하여 모듈성과 확장성을 향상시킴
• WebHooks의 과제
• 오류 처리: 웹훅 수신 측이 다운되거나 콜백 처리에 오류가 있는 경우 데이터 손실 위험이 있음. 웹후크를 사용하는 시스템에는 재시도 또는 로그를 포함한 강력한 오류 처리 메커니즘이 있어야 함
• 보안 문제: 웹훅은 인터넷을 통해 데이터를 전송하므로 데이터를 가로채거나 악의적인 공격에 취약하게 만듦. HTTPS 및 페이로드 서명 사용과 같은 API 보안 조치가 필수적
• 여러 웹훅 관리: 웹훅 관리 및 모니터링은 복잡할 수 있음. 특히 애플리케이션이 성장하고 여러 웹훅에 의존하기 시작하면 더욱 그렇게 됨. 모든 웹후크가 올바르게 작동하고 다양한 엔드포인트를 추적하려면 주의가 필요
• 과부하 가능성: 대량의 동시 콜백으로 인해 애플리케이션 수신이 부담될 수 있지만 속도 제한이나 일괄 처리는 급증 관리에 도움이 될 수 있음

​

#GraphQL

• GraphQL은 API용 쿼리 언어이자 데이터에 대해 정의한 유형 시스템을 사용하여 쿼리를 실행하기 위한 서버 측 런타임
• 2012년 Facebook에서 개발하고 2015년 오픈 소스 프로젝트로 출시된 GraphQL은 기존 REST API에 대한 보다 유연하고 효율적인 대안을 제공
• GraphQL은 개발자들 사이에서 채택률이 29%로 증가하고 있으며 이는 오늘날 API 환경에서 그 중요성이 나타나고 있음
• 관련 데이터를 가져오기 위해 여러 API 엔드포인트를 거쳐야 하는 REST와 달리 GraphQL을 사용하면 단일 쿼리에서 필요한 모든 데이터를 얻을 수 있음
• 이는 데이터 검색 프로세스에 대한 더 많은 제어권을 제공하고 더 동적이고 반응성이 뛰어난 사용자 인터페이스를 만들 수 있도록 해주기 때문에 프런트엔드 개발자에게 특히 유용
• GraphQL의 장점
• 강력한 형식의 스키마: GraphQL API에는 강력한 형식의 스키마가 있으므로 개발자는 쿼리에 사용할 수 있는 데이터와 유형을 정확히 알 수 있음
• 정확한 데이터 검색: 클라이언트는 필요한 정확한 데이터를 요청할 수 있으며, 이는 오버-펫칭 및 언더-펫칭 문제를 해결하고 더 나아가 성능을 향상시키고 비용을 절약
• 쿼리 복잡성 및 다양한 리소스: GraphQL은 하나의 요청으로 여러 데이터 유형 쿼리를 지원하므로 복잡하고 상호 관련된 데이터에 대한 네트워크 요청 수가 줄어듦
• 구독을 통한 실시간 업데이트: GraphQL은 구독을 통해 실시간 동기화를 지원하므로 클라이언트가 실시간으로 업데이트됨
• 내성: GraphQL의 자체 문서화 스키마를 사용하면 자체 검사를 통해 더 쉽게 개발할 수 있음
• GraphQL의 과제
• 쿼리 복잡성: GraphQL이 클라이언트에 제공하는 유연성에는 단점이 있음. 지나치게 복잡하거나 중첩된 쿼리는 성능에 부정적인 영향을 미칠 수 있기 때문
• 학습 곡선: GraphQL은 돌연변이 및 구독과 같은 새로운 개념으로 인해 REST보다 학습 곡선이 더 가파름
• 버전 관리: 쿼리의 유연한 특성은 스키마 변경으로 인해 기존 쿼리가 중단되고 버전 관리가 복잡해질 수 있음을 의미
• 리소스의 과도한 사용 가능성: 클라이언트는 하나의 쿼리로 여러 리소스를 요청할 수 있으므로 필요한 것보다 더 많은 데이터를 가져와 서버에 과부하가 걸릴 위험이 있음
• 보안 문제: 악의적인 사용자는 GraphQL의 유연성을 악용하여 복잡한 쿼리로 서버에 과부하를 줄 수 있음

​

#SOAP

• SOAP(Simple Object Access Protocol)는 웹 서비스를 구현하기 위해 구조화된 정보를 교환하기 위한 프로토콜
• 메시지 형식으로 XML을 사용 하고 일반적으로 메시지 협상 및 전송 계층으로 HTTP 또는 SMTP를 사용
• REST 및 GraphQL과 달리 SOAP에는 ACID 호환 트랜잭션, 보안, 메시징 패턴과 같은 엄격한 표준과 내장 기능이 있음
• 개발자의 26%에 불과한 사용량 감소에도 불구하고 SOAP는 특정 애플리케이션에 대해 신뢰할 수 있는 선택
• SOAP의 장점
• 강력한 타이핑 및 계약: WDSL(Web Services Description Language) 문서에 정의된 강력한 유형 지정 및 엄격한 계약이 있음
• 내장된 보안 기능: SOAP는 WS-Security 표준을 통해 구현된 인증 , 권한 부여 및 암호화를 통해 포괄적인 보안을 제공. 이로 인해 엔터프라이즈 애플리케이션에 선호되는 선택
• ACID 거래: SOAP는 금융 또는 의료 시스템과 같이 데이터 무결성이 중요한 애플리케이션에 필수적인 ACID 트랜잭션을 지원
• 안정적인 메시징: SOAP는 안정적인 메시지 전달을 보장하고 오류를 잘 처리하므로 메시지 전달 보장이 중요한 시스템에 매우 적합
• 언어, 플랫폼 및 전송 중립성: REST와 마찬가지로 SOAP 서비스는 기본 프로그래밍 언어, 플랫폼 또는 전송 프로토콜에 관계없이 XML을 이해하는 모든 클라이언트에서 사용할 수 있음
• SOAP의 과제
• 복잡성 및 학습 곡선: SOAP는 엄격한 표준과 XML 사용으로 인해 구현하기가 더 복잡할 수 있으므로 REST 또는 GraphQL과 같은 대안보다 학습 곡선이 더 가파름
• 자세한 메시지: SOAP 메시지 헤더는 많은 오버헤드를 전달하므로 REST 및 GraphQL의 JSON 보다 페이로드가 더 커짐 . 이는 성능과 대역폭 사용량에 영향을 미칠 수 있음
• 제한된 커뮤니티 지원: SOAP는 기반을 잃어가고 있으며 이는 커뮤니티 지원과 사용 가능한 라이브러리가 감소하고 있음을 의미
• 유연성이 떨어짐: 계약이 변경되면 클라이언트와 서버 모두 각각의 구현을 업데이트해야 할 수 있으며 이는 단점이 될 수 있음
• 방화벽 문제: SOAP는 HTTP/HTTPS와 다른 전송 프로토콜을 사용할 수 있으며 이는 방화벽 제한에 직면할 수 있음을 의미. 이로 인해 일부 배포 환경에서는 SOAP의 다목적성이 떨어짐

​

#WebSocket

• WebSocket은 클라이언트와 서버 간에 지속적이고 대기 시간이 짧은 양방향 연결을 제공하여 실시간 데이터 전송이 가능
• HTTP의 요청-응답 주기와 달리 WebSocket을 사용하면 서버는 초기 핸드셰이크 이후 언제든지 클라이언트에 데이터를 보낼 수 있음
• 채팅 애플리케이션, 온라인 게임, 거래 플랫폼 등에 대한 즉각적인 데이터 업데이트가 용이
• 설문 조사에 따르면 개발자의 25%가 WebSocket을 사용하는 것으로 나타남
• WebSocket의 장점
• 실시간 양방향 통신: 실시간 양방향 통신은 교환할 때마다 다시 설정해야 하는 HTTP 연결보다 대기 시간이 짧음
• 간접비 절감: 초기 핸드셰이크 후에도 연결은 계속 열려 있으므로 기존 HTTP 요청과 함께 제공되는 헤더의 오버헤드가 줄어듦
• 자원의 효율적인 사용: 영구 연결은 긴 폴링보다 서버 리소스를 더 효율적으로 사용
• WebSocket의 과제
• 구현 복잡성: WebSocket 구현은 다른 API 아키텍처보다 더 복잡하고 시간이 많이 걸릴 수 있음. 특히 WebSocket이 지원되지 않는 환경에서 대체의 필요성을 고려할 때 더욱
• 내장 기능 부족: 보안 및 트랜잭션을 위한 기능이 내장되어 있는 SOAP와 달리 WebSocket은 기본에 가까워 개발자가 이러한 기능을 직접 구현해야 함
• 자원 소비: 개방형 WebSocket 연결은 일반적으로 장기 폴링 기술보다 더 효율적이지만 여전히 서버 리소스를 소비하며 대규모로 문제가 될 수 있음
• 네트워크 제한: 일부 프록시 및 방화벽은 WebSocket을 지원하지 않으므로 특정 네트워크 환경에서 잠재적인 연결 문제가 발생할 수 있음

​

#gRPC

• "Google Remote Procedure Call"을 의미하는 gRPC는 서비스 간 통신을 용이하게 하는 최신 고성능 프로토콜
• HTTP/2 위에 구축되었으며 프로토콜 버퍼를 활용하여 서비스 방법과 메시지 형식을 정의
• GET 및 POST와 같은 표준 HTTP 동사를 사용하는 REST API와 달리 gRPC는 서비스에서 프로그래밍 언어의 기능과 유사한 사용자 지정 메서드를 노출할 수 있도록 지원
• gRPC의 장점
• 성능: HTTP/2 및 프로토콜 버퍼를 사용하면 gRPC가 짧은 대기 시간과 높은 처리량을 달성할 수 있음
• 강력한 타이핑: SOAP 및 GraphQL과 마찬가지로 gRPC는 강력한 형식입니다. 결과적으로 컴파일 타임에 유형이 검증되므로 버그가 줄어듦
• 다중 언어 지원: gRPC는 Go, Java, C# 및 Node.js를 포함한 다양한 프로그래밍 언어를 최고 수준으로 지원
• 스트리밍: gRPC는 즉시 스트리밍 요청 및 응답을 처리하여 장기 연결 및 실시간 업데이트와 같은 복잡한 사용 사례에 적용 가능
• 배터리 포함: gRPC는 부하 분산, 재시도 및 시간 초과와 같은 중요한 기능을 직접 지원
• gRPC의 과제
• 브라우저 지원: 브라우저의 기본 gRPC 지원은 여전히 ​​제한되어 있으므로 웹 애플리케이션의 클라이언트-서버 직접 통신에는 적합하지 않음
• 학습 곡선: 개발자는 초기 생산성을 저하시킬 수 있는 프로토콜 버퍼, 사용자 지정 서비스 정의 및 기타 gRPC 기능을 사용하는 방법을 배워야 함
• 디버깅 복잡성: 프로토콜 버퍼는 사람이 읽을 수 없으므로 JSON API보다 gRPC API를 디버깅하고 테스트하기가 더 어려움

​

기타 API 프로토콜

#MQTT : IoT와 같은 저대역폭 네트워크에 최적화된 경량 메시징 프로토콜. 클라이언트가 브로커를 통해 메시지를 게시하고 구독할 수 있지만 일부 보안 및 확장성 기능이 부족

#AMQP : 안정적인 메시지 전달과 유연한 메시지 라우팅을 보장하는 더욱 강력한 엔터프라이즈 메시징 표준. 그러나 이는 경량 프로토콜보다 복잡할 수 있고 오버헤드가 더 많음

#SSE : HTTP를 통한 단방향 서버-클라이언트 통신을 가능하게 하며, 실시간 업데이트에는 적합하지만 양방향 기능이 부족

#EDI : 구매 주문서, 송장 등의 전자 문서를 표준화하여 B2B 커뮤니케이션을 자동화하지만 초기 비용이 많이 들고 복잡한 인프라도 필요

#EDA : 구성요소가 이벤트에 반응하는 이벤트 중심 아키텍처를 촉진하여 확장 가능하면서도 디버깅이 복잡한 실시간 시스템을 가능하게 함

결론

• 개발자가 새로운 아키텍처, 프로토콜 및 도구를 채택함에 따라 API 환경은 계속 발전하고 있음
• REST는 단순성과 편재성으로 인해 여전히 지배적이지만 GraphQL 및 gRPC와 같은 대안은 과도한 가져오기 및 수다스러운 인터페이스와 같은 문제점을 해결하여 관심을 얻고 있음
• 또한 개발자들은 실시간 통신에 대한 요구 때문에 WebHooks와 WebSocket을 점점 더 중요하게 여기고 있음
• 많은 일반적인 API 사용 사례에서 REST는 확장성, 상호 운용성 및 채택 용이성을 고려하여 견고한 기본 접근 방식으로 남아 있음. 또한 커뮤니티 성숙도의 이점도 있음
• 그럼에도 불구하고 모든 프로토콜에는 장단점이 있으며 애플리케이션이 더욱 복잡해짐에 따라 개발자는 GraphQL 및 gRPC와 같은 특수 솔루션을 포함하도록 API 프로토콜 툴킷을 현명하게 확장중
• 모든 경우에 적용되는 일률적인 만병통치약보다, API 개발자는 여러 프로토콜의 강점과 약점을 이해하는 것이 가장 좋음
• REST, WebHook, WebSocket, GraphQL 및 각각 고유한 장점을 지닌 기타 접근 방식을 결합한 시스템을 설계함으로써 개발자는 강력하고 효율적이며 유지 관리가 가능한 API를 구축할 수 있음
• 개별 프로토콜의 인기는 계속해서 변동하겠지만, 가장 중요한 추세는 API 환경에서 다양성이 증가하는 것
• 개발자는 최적의 API 솔루션을 만들기 위해 이러한 다중 프로토콜 철학을 수용해야 함